In-house разработка
81 subscribers
36 photos
17 links
За консультациями пишите в личку: @anikolaev_ru
Download Telegram
In-house разработка pinned «Дорогие мои друзья и подписчики! За почти полгода напряженной проектной работы и молчания в этом канале, я увидел свою основную профессиональную ценность. В отличие от многих других бизнес-консультантов по управлению IT-разработкой, я знаю и умею настраивать…»
Конфликт - это всегда какое-то несовпадение точек зрения из-за недостаточно детально прописанного регламента или из-за его неправильного применения. Поэтому, чтобы решить конфликт между сотрудниками, руководитель детально разбирается в ситуации и корректирует либо регламент, либо проводит дополнительный инструктаж.

Руководитель может это делать, потому что лучше своих подчиненных знает зачем и как делать эту конкретную работу. В разработке всё наоборот. Любой технический руководитель (тимлид, техдир, IT-директор, и т.д.) со временем неизбежно размывает свою специализацию по всему стэку технологий продукта, теряя её высоту. В результате, разработчики лучше руководителя разбираются в конкретных технологиях, которые применяются на проекте.

Поэтому, принимаемые руководителем технические решения, например, в части проектирования взаимодействия между компонентами архитектуры, оставляют желать лучшего. Это сильно демотивирует разработчиков, вовлеченных в конфликт потому, что они вынуждены делать хуже, чем хотят и могут. Обычно, это заметно слишком поздно - разработчики требуют повышения зарплаты вплоть до ультиматумов об увольнении.

Чтобы правильно решить конфликт, нужно свести все конфликтующие стороны на прямой диалог. Затем нужно помочь людям услышать друг друга с помощью открытых вопросов. Когда разработчики слышат друг от друга новые для себя ограничения и возможности, они начинают генерировать новые решения. Поэтому важно в диалоге отвязать варианты решения от имени их авторов, наделив их осмысленными наименованиями. Одно из новых решений будет принято всеми как оптимальное.

Роль руководителя в том, чтобы вести переговоры, а не судить и принимать решения. Третейский судья, посредник, переговорщик, решала - это всё проигрышные роли для руководителя. Скорее подойдет медиатор, фасилитатор. Важно сразу же обозначить тайминг и цель встречи - найти оптимальное решение. Чтобы успеть за отведенное время, нужно заранее прикинуть фасилитационный план. Всё это может быть сложно и непрофильно для руководителя, поэтому хорошо иметь специально обученного человека, который умеет фасилитировать встречи и помогать решать конфликты.
В прошлый раз я написал о роли руководителя в разрешении конфликтов. Однако, любой профессиональный руководитель хочет знать причины появления этих конфликтов, чтобы работать на упреждение. И они есть, конечно же.

Во-первых, конфликт - это не всегда плохо. Плохой, нездоровый конфликт приводит к пустой потере времени и денег, демотивирует специалистов, провоцирует их увольнение, снижает качество и эффективность работы. Хороший, здоровый конфликт всегда приводит к повышению эффективности командной работы.

Во-вторых, отсутствие конфликта ещё не означает, что у вас слаженная команда, которая работает на результат. Чаще всего люди стараются избегать конфликтов, старательно обходя острые темы в коммуникациях. А что если как раз в этих темах закопаны узкие места? Получается что команда прилагает усилия, чтобы сдержать рост эффективности, а руководитель ничего не может с этим сделать.

Получается наоборот - здоровые конфликты чрезвычайно полезны и нужны. Но как сделать, чтобы было больше здоровых конфликтов, и меньше нездоровых? Есть несколько факторов, блокирующих полезные конфликты. Приведу их в порядке влияния.

Неправильная конфигурация команд. Самый серьезный фактор, который создает огромные проблемы не только в отношениях, но и в архитектуре продукта (см. закон Конвея). Будучи включенным в одну из команд, сотрудник автоматически считает сотрудников своей команды своими, а сотрудников других команд чужими. Это легко можно услышать в речи, когда употребляются слова “мы” и “они”.

Правильный сетап команд - кросс-функциональные кросс-компонентные. Да, я видел конфликты, например, двух дизайнеров из разных продуктовых команд (нон-сенс для проектно-матричной структуры!). Однако, такие неразрешенные конфликты оказывают гораздо меньше влияния на результат, чем конфликты между сотрудниками, разрабатывающими один и тот же продукт.

Вроде бы, должно помочь естественное выделение ответственности в функциональных руководителей, которые априори лучше разбираются в технологиях своих подчиненных, и поэтому они смогут правильно решать все конфликты между своими подопечными. Однако, это напрямую приводит к появлению неправильного сетапа команд, даже если их и пытаться собирать в более-менее постоянные проектные структуры.

Отсутствие доверия. По сути это означает, стать более уязвимым по отношению к коллегам. Буквально, перестать защищаться от них. Быстро это не лечится, но первый шаг очень простой: добровольно рассказать коллегам о себе вне рабочего контекста. Такой рассказ естественным образом снижает защитный “экран”. Есть специальные упражнения, с помощью которых можно сделать такую процедуру за 15 минут.

Отсутствие правил коммуникации. Люди не решаются вступать в дискуссии по острым вопросам потому, что элементарно не знают, как и что можно говорить? Решается очень просто: собраться и совместно написать эти правила. Их не должно быть много: 5-8 правил достаточно. На то, чтоб сделать такой свод правил нужно максимум полчаса.

Друзья, разбивайте свои команды правильно. И пусть у вас в разработке всегда работают мотивированные профессионалы.
Почему разработчики сопротивляются и даже отказываются добавлять новый функционал с возражениями типа “это невозможно”, “в изначальном ТЗ этого не было”, “мы это не предусмотрели”?

Встречаясь с таким, заказчик постепенно привыкает к мысли о том, что надо изначально делать универсальный функционал, который подойдет под любую ситуацию. Разработчики с радостью берутся такое делать, потому что это означает много интересной работы по моделированию и проектированию всяких разных абстракций без необходимости хоть сколько нибудь сильно погружаться в производственный или бизнесовый контекст.

В итоге, разработка становится очень долгой и затратной. В конечном итоге, когда всё это выходит в прод, оно оказывается практически бесполезным, потому что не решает никакую конкретную задачу. Но ведь именно это разработчиков и просили делать - сделать некий абстрактный функционал, который потом можно будет приспособить под какую-то конкретную задачу.

Суть в том, что абсолютно гибкий функционал создать невозможно. Любая архитектура - это некоторая жесткость, которая принципиально фильтрует набор задач, под который она может быть применена. Как же создать гибкую архитектуру, которую затем достаточно быстро и дешево можно будет дорабатывать?

На самом деле, программный код - это всего лишь часть нормативной документации предприятия. Такой же как, например, должностные и рабочие инструкции сотрудников. И если программный код писать исходя из модели конкретного производственного или бизнес-процесса, то он не будет вступать в серьезный конфликт с любого рода запросами на доработки от владельцев и сотрудников этого самого производства/бизнеса.

Поэтому сначала нужно погрузить разработчиков в существующий производственный или бизнес-процесс, эффективность которого требуется повысить с помощью разработки. Изучение можно останавливать, когда разработчики могут уверенно рассказать о том, как пользователи работают сейчас без будущего функционала продукта. Теперь можно приступать к написанию ТЗ.

Для этого просим разработчиков придумать функционал и опять сводим их с пользователями: разработчики рассказывают/показывают функционал, а пользователи смотрят/слушают и затем рассказывают, как они они будут им пользоваться. Скорее всего там понадобится несколько итераций. Когда мы убедились, что они нашли взаимопонимание, можно фиксировать договоренности документально и приступать к работе.
Эффективная разработка - это когда проблема заказчика решена с минимальными инвестициями (капитальными затратами) и расходы на владение решением остались в пределах разумного.

Однако, очень часто разработчики пилят то, что вроде бы работает, но проблему по большому счету не решает. Их приходится тыкать во вроде бы очевидные нестыковки, они идут доделывать и переделывать. При этом они сильно демотивируются. Расходы при этом конечно же выше (иногда сильно выше), чем это выглядело при принятии решения на старте разработки. А ещё нередко при этом разработчикам приходится, что называется, костылять и велосипедить, из-за чего вырастает (иногда очень сильно) стоимость всех последующих доработок в связанных компонентах продукта.

Причина в том, что у каждого из участников разработки узкая специализация. Заказчик обладает экспертизой в бизнесе, но он не разбирается в технологиях. Каждый из разработчиков хорошо разбирается в какой-то одной, максимум двух, технологиях, и не разбирается в других. Они все друг друга изначально настолько плохо понимают, что даже избегают общаться напрямую, предпочитая отгораживаться разного рода прокладками в виде тимлидов, техлидов, менеджеров проектов, аналитиков и т.д.

Поэтому очевидное решение - с самого начала ради успеха проекта договариваться напрямую по всем вопросам. Не лениться документировать принятые решения так, чтобы всем участникам, включая заказчика, они были понятны. Однако, такой выход из зоны комфорта требует усилия, и если хотя бы один участник выпадает, или прилагает недостаточно усилий, вышеназванные проблемы не заставят себя долго ждать. Поэтому так важно иметь в команде специально обученного человека, который помогает своевременно договариваться, чтобы ложные ожидания не превращались в проблемы. В англоязычной среде его называют Servant Leader - обслуживающий лидер.

Любой квалифицированный проектный менеджер ведет себя как Servant Leader, выполняя 4 основных роли: ментор, тренер (учитель), фасилитатор и коуч. Если вы хотите подробнее узнать об этих 4 ролях, то для вас я разместил у себя на канале короткий видеоролик буквально на 3 минуты из довольно старого, но до сих пор весьма актуального доклада Асхата Уразбаева "Agile Coach и Scrum Master как руководители нового типа". Приятного просмотра!
Когда-то давно, лет 20 назад, я работал инженером в колледже. Мой руководитель узнал о моём сильном желании чего-то разрабатывать и предложил мне написать какую-то программу для учета в учебном процессе. Для этого мне надо было сходить к завучу и выяснить, что именно надо сделать.

Я пришел к завучу и стал спрашивать, как должна выглядеть программа? Какие там должны быть экраны, поля и т.д. И когда завуч сказал, что понятия не имеет, я был в шоке и даже не знал, что спросить. Так мы молча стояли и смотрели друг на друга несколько минут: завуч ждал нормальные вопросы, а я ждал нормальное ТЗ.

Ушел я тогда не солоно хлебавши, думая по молодецкой глупости, что мне просто попался неквалифицированный заказчик. И отчасти, это правда. Есть такое понятие в продажах IT-проектов: квалификация. Продавцы проблематизируют заказчика, чтобы с одной стороны отсеять нецелевого клиента, а с другой стороны получить осмысленный запрос на IT-разработку.

Однако дальше, после квалификации, к заказчику идет аналитик и обычно задает эти самые вопросы в духе "чего изволите". И хорошо, если заказчик честно скажет, что не знает, как было в моём случае. Новичкам, видимо, действительно везёт! Чаще всего заказчик начинает фантазировать, а аналитик всё это тщательно фиксирует, уточняя всё до мелочей и пытаясь выстроить это всё в какую-то непротиворечивую картину и описать в техзадании.

В результате такого подхода всегда получается большое ТЗ и соответственно большой проект. И даже если проектная команда смогла реализовать ТЗ в изначально оговоренный срок и бюджет (почти никогда такое не происходит), есть очень большая вероятность, что заказчик будет разочарован. Да, конечно, умелые продавцы и руководитель проекта натыкают заказчика в ТЗ и убедительно докажут, что тот сам виноват. Но разве такой подход можно назвать профессиональной разработкой?

Никакой заказчик никогда не хочет и не будет хотеть получить то, что написано в ТЗ. Для него функционал продукта - это всегда только расходы. Разовые расходы на переобучение пользователей и постоянные расходы времени самих пользователей на работу с программой. Заказчик хочет получить не функционал, а какой-то бизнес-результат, какое-то изменение в бизнесе за счет переключения пользователей на новый функционал.

Но подход “чего изволите” в процессе анализа в разработке не дает заказчику бизнес-результат. С какого перепугу мы можем рассчитывать получить иной бизнес-результат, не меняя при этом методы и способы его получения? Генри Форд говорил: “Если б я спрашивал у своих клиентов, чего они хотят, я бы сделал быструю лошадь.” Проблема в том, что все хотят изменений, но сами меняться не хотят. Это естественно.

Получается, что подход “чего изволите” сработает только если заказчик уже сам додумался, что надо менять не только и не столько функционал продукта, сколько саму работу пользователей, операционный бизнес-процесс. Такой квалифицированный заказчик оперирует не требованиями, а проблемами или гипотезами получения эффекта от тех или иных изменений в пользовательском опыте своих сотрудников.

Поэтому ключевая функция аналитика в проектной команде не в том, чтобы придумать функционал и расписать его в ТЗ, а в том, чтобы изучить и понять текущий пользовательский опыт, проблемные точки в нём и целевой пользовательский опыт. Требуемый в связи с этим функционал с удовольствием придумают разработчики, а заказчик получит возможность существенно сэкономить время и деньги на решение своих задач.

Есть много разных инструментов, которые может использовать аналитик для того, чтобы выполнить толковый анализ. Один из них - impact mapping. Сначала описываем желаемый для заказчика эффект, затем людей, чей пользовательский опыт надо изменить для получения эффекта, затем гипотезы целевого пользовательского опыта, а самую правую колонку предлагаем заполнить разработчикам - получится бэклог продукта, который при желании можно упаковать в ТЗ.
Действительно крутой продукт может сделать только крутая команда. Поэтому, чтобы сделать крутой продукт, нужно собрать крутую команду. Вы тоже так думаете? Тогда у меня для вас плохие новости. Первое утверждение бесспорно, второе утверждение - заблуждение. Но почему-то именно такое заблуждение я нередко встречаю в предпринимательской среде.

Предприниматель мечтает о крутой команде, а собрав выдающихся людей в свою команду, он всячески их удерживает вместе, ожидая от них крутых достижений. Аналогичное заблуждение - в крутой команде работают выдающиеся люди, поэтому надо собрать выдающихся людей, чтобы получить крутую команду.

Для всех подобных убеждений у меня в голове крутится выражение “натягивать сову на глобус”. А когда я вижу активные действия с этими убеждениями, у меня возникает образ попытки гладить кошку против шерсти. И чтоб при этом не страдать от её раздраженных укусов и ударов когтями (разгребать конфликты и закидоны), на руку надевается прочная перчатка-верхонка - наемные менеджеры или недалекие бизнес-партнеры.

Коллеги-предприниматели, я убежден, что это ваша сильная сторона - идти против течения, чтобы делать локальные революции на рынках и отраслях. Но для того, чтобы получить крутую команду, надо делать совсем иные действия. Людьми управляют идеи или деньги. И в зависимости от того, что из этих двух вещей для вас приоритетнее, нужно использовать соответствующий подход к формированию и управлению командой.

Если для вас важнее идея, то вы готовы пойти в менее прибыльную и трудную историю, если это сделает вас ближе к реализации вашего идеала. Конечно, вы понимаете, что нельзя оказать хоть сколько-нибудь масштабное влияние, не найдя прибыльную бизнес-модель. Но деньги для вас всё же вторичны. Вы управляете людьми через идею, и поэтому не испытываете ограничений роста и масштабирования бизнеса. 

Если для вас деньги важнее, то ваш подход: “Помоги мне сделать бизнес, и я с тобой поделюсь”. Не надо рассказывать людям о высокой идее, миссии и прочих высоких материях. Будьте честны: вы легко готовы менять идеи ради денег, и это хорошо. Ваша принципиальность не в том, чтобы до конца следовать какому-то идеалу, а в том, чтобы держать своё слово.

Дальше проще. Когда вы правильно привлекаете и мотивируете людей исходя из своих приоритетов, вам уже не нужны выдающиеся люди на старте. Поверьте, что они станут выдающимися, делая вместе с вами ваш продукт. Самые обычные люди, с которыми вы с самого начала установили честные отношения, сработаются друг с другом и станут крутой командой. Нужно только убедиться, что все в команде одинаково понимают задачу и в команде хватает компетенций для её решения.

Общее понимание возникает, когда вы последовательно раскручиваете: цель, видение и план. Интересно, что вы можете ограничиться лишь целью, а видение и план предложить разработать команде, тогда команда будет более самоходной. Цель отвечает на вопрос “зачем”, прозрачно очерчивая командную ответственность за результат. Видение отвечает на вопрос “как”, это своего рода обезличенная схема достижения цели. А план - это конкретные действия конкретных людей в команде.

Чтобы убедиться в наличии компетенций, хорошо подходит формат матрицы, которую можно нарисовать вместе с ранними членами команды - собрались на двоих/троих и нарисовали. По вертикали располагаются имена людей в команде, по горизонтали - необходимые компетенции, на перекрестии - уровень владения.

Дальше прорабатываем риски выпадения членов команды, т.н. bus factor - сколько человек должен сбить автобус, чтобы работа команды остановилась. Делим уровень владения на два (условно “эксперт” и “могу сделать, но не очень хорошо”) и выделяем условное обозначение для “не могу, но хочу научиться”. Такой “экран” наглядно покажет пробелы, узкие места и возможности команды на старте.

Друзья мои, не натягивайте сову на глобус, не питайте ложных ожиданий от людей. Правильно собирайте и честно мотивируйте команду, и пусть у вас всё получится!
Этот иностранный термин обозначает срок выполнения работ. Очень часто я вижу, как дедлайны используются для контроля выполнения работ вплоть до убежденности в том, что без дедлайна задача в принципе не будет сделана. Например, в корпоративном планировщике в одной из компаний отсутствие дедлайна для задачи помечается также, как просроченный дедлайн.

Проблема в том, что по эмпирическому закону Паркинсона, любая работа растягивается и занимает всё отведенное на неё время. Выставляя дедлайн, мы убираем возможность сэкономить на конкретной работе. Чаще всего под дедлайном прячется не срок, а всего лишь прогноз, оценка исполнителя. Иначе говоря, даже если мы разделим срок и оценку, проблема всё равно останется.

Дедлайны иногда срываются, это естественное следствие ошибок в управлении. И в этих случаях дедлайн обычно используется как плетка - выговоры, наказания, санкции. Он ведь не зря именно так называется - dead line (линия смерти). Сделай или умри. Это приводит к тому, что исполнитель закладывает подстраховку в свою оценку. И чем больнее плетка, тем больше будет подстраховка. Постепенно дедлайны, как средство контроля, вырождаются и работа без них в принципе не выполняется: если человека постоянно лупить за дедлайны, то он в принципе перестает воспринимать задачи без них.

Получается, что использование дедлайнов для контроля проекта системно приводит к распуханию этого и всех будущих проектов данной проектной команды. Но что делать? Надо же как-то контролировать проект! Если оставить его без контроля, то он вообще не будет сделан. А вот это довольно распространенное заблуждение, что контролировать можно только через дедлайны.

Для начала следует отделить проектную работу от операционной. Операционная - это когда надо делать плюс-минус одинаковые действия для получения плюс-минус одинакового результата. По этой причине операционные задачи достаточно легко предсказываются и нормируются, и дедлайны, как метод контроля, вполне годятся. Проектная работа, наоборот - каждый раз разный результат. А иначе зачем снова делать то, что уже сделано? Для проектных задач нужен другой способ.

Если операционные процессы предприятия, как область проведения проектных работ, достаточно хорошо упорядочены, можно воспользоваться эмпирически накопленными данными о сроках выполнения похожих работ. Ищем похожие по сложности работы в прошлом и смотрим фактические сроки их выполнения. Например, надо настроить web-сервер. Смотрим сколько времени в прошлом у нас уходило на такие web-сервера? От 2х до 4х дней. Убеждаемся, что у исполнителей есть все необходимые ресурсы, они хорошо поняли задачу и их никто не отвлекает. Этого достаточно, чтобы работа была сделана вовремя.

Что делать если в результате злоупотребления дедлайнами подстраховка стала слишком большой и есть соответствующие проблемы? Нужно начать измерять фактическое время выполнения всех работ и регулярно анализировать его с целью сокращения. Лично у меня позитивный опыт использования kaiten для этого: визуализируем работу на канбан-доске, каждый день двигаем карточки и регулярно (раз в неделю-две) смотрим отчеты.

На отчетах смотрим задачи-выскочки, время которых по сравнению со всеми остальными слишком большое. Если у нас поток не нормированный (все задачи разные по трудоемкости), то нужно делать оценку задач в относительных функциональных единицах (попугаях, story point-ах) и для анализа использовать спектральный график: жмем в колонку и ищем те задачи, которые по оценке сильно меньше, чем другие. Далее открываем историю по каждой выскочке и ищем системные факторы, которые можно убрать. Если поток уже нормированный, то можно использовать контрольных график.

Делая так мы постепенно увидим положительную динамику на графике времени цикла. Совершенству нет предела, но за 20% усилий по такому ретроспективному анализу вы получите 80% сокращения затрат.
Когда я встречаюсь с коллегами по цеху и делюсь с ними своим опытом запуска и поддержки самоорганизованных команд в IT-разработке, то часто слышу скептическое “не верю, так не работает”. Меня пытаются убедить, что разработчики не могут работать без руководителя, это иллюзия. Я понимаю, откуда растут ноги у такого неприятия и с вами с удовольствием поделюсь. Оказывается, есть три уровня управления командами по степени устойчивости в плане предсказуемости.

Первый уровень: микроменеджмент. Руководитель непосредственно каждому раздает задачи, координируя людей в процессе их выполнения, чтобы получить результат для заказчика (бизнеса). На этом уровне оказывается тимлид, который совсем ещё недавно был технарем. Да, это очень просто и эффективно. Бизнесу удобно - всегда есть конкретный человек, который отвечает за всё в команде. Однако устойчивость крайне низкая - всё зависит от одного человека, без которого коммуникация ломается и всё встает колом. Причем заменить его крайне сложно, потому что с новым руководителем весь процесс выстраивается с нуля.

Второй уровень: процессное управление. Руководитель распределяет роли и настраивает операционное взаимодействие между разными участниками в команде так, чтобы результат был получен. На этом уровне работают профессиональные проектные менеджеры. Это сложно, нужна достаточно хорошая квалификация в менеджменте. Однако, даже при наличии таковой, строго регламентированные роли в команде, будучи настроенными вручную с одной стороны ограничивают и демотивируют людей, с другой стороны неизбежно создают дыры в общей зоне ответственности команды. В начале проекта процесс идет бодренько, но ближе к концу проекта скапливаются очереди из вовремя неразрешенных проблем и противоречий между ролями, и проект распухает.

Третий уровень: самоорганизация. Руководитель показывает команде результат, который нужен бизнесу и затем помогает команде самостоятельно договориться по ролям, взаимодействию и необходимой прозрачности процесса. Руководитель всё ещё есть, но его управление становится неявным. Члены команды делают то, что ему нужно, но без его непосредственных предписаний. Роли всё ещё есть, но участники сами их определяют и распределяют между собой. Оказывается, что это крайне сложно для руководителя - требуется хорошая квалификация в менеджменте, коучинге и фасилитации.

Интересно, что внешне работа команды на третьем уровне не отличается от второго уровня. Отличие проявляется в том, как участники реагируют на необходимость перестроиться. На втором уровне это делает руководитель вручную, меняя регламент. На третьем уровне, команда это делает самостоятельно. У меня с этим очень резонирует образ игры на детской площадке, где дети сами распределяют и перераспределяют роли в зависимости от состава и ситуации.

Третий уровень, не смотря на всю сложность достижения, дает бизнесу очень много преимуществ. Например, это очень высокая мотивация членов проектной команды. У меня были реальные случаи, когда люди не уходили из такой команды несмотря на то, что их догоняли рекрутеры из других компаний предлагая сильно больше денег. На мой вопрос “почему” я слышал ответ “нравится атмосфера”, хотя это не был самый лучший офис, техника, не самый крутой проект, и прочее.

Уже даже и речи нет о проблемах коммуникации между членами проектной команды. Необходимое для получения результата общение происходит неформально, почти всегда вовремя и ровно в той степени, какая необходима. Никто не жалуется на скучные ненужные совещания, люди сами определяют необходимый состав собрания и сами контролируют присутствие.

Высокая гибкость процесса и автономность (самоходность). Команда самостоятельно подстраивается под меняющиеся требования, условия, самостоятельно ищет решения для проблем, эскалируя руководителю только внешние. Контроль проекта происходит также без видимого участия руководителя. Члены команды заранее обучаются и подменяют друг друга при выпадении по болезни или отпуска. Они сами контролируют своевременно выполнение задач и указывают друг другу на соответствующие проблемы.
Всё ещё есть необходимость решать внешние проблемы, создавать хорошие условия и активно вмешиваться при попытках нарушить границы дозволенного. Нужно периодически организовывать командообразующие мероприятия. Нужно быть готовым к тому, что нельзя просто так нанять и уволить человека без учета мнения такой команды. Нужны значительные усилия по обеспечению прозрачности бизнес-запроса, целей разработки. Наконец, нужно очень много терпения руководителя, потому что на пути к третьему уровню команда будет много раз ошибаться, чтобы научиться.

Как этому научиться? Нужно признать, что это возможно и захотеть перейти на третий уровень - пожалуй, это самое сложное. Нужно быть действительно экспертом в проектном менеджменте, чтобы по существу отвечать команде на вопросы и быть способным вместе с ними находить необычные приемы по части самоуправления. Очертите границы, за которые команда не должна переходить в своих экспериментах, сделайте их прозрачными и сохраните за собой право применять административный ресурс на этот случай.

Кажется, что я не смогу описать всё, что нужно для этого в тесных рамках одного поста. Но для этого я собственно и завел этот канал, чтобы делиться с вами, выпуская один пост за другим, когда появляется возможность. Оставайтесь на связи!
Основатель бизнеса знает и может организовать всё в своём бизнесе: и маркетинг, и продажи, и производство. Иначе есть риск, что бизнес придется закрыть при уходе сотрудника-носителя уникального знания. Но IT-разработка всегда будет находиться в слепой зоне у основателей по одной простой причине: слишком сложно.

Технический директор, который создал минимально-необходимую автоматизацию на старте, не спасает. Потому что IT-инфраструктура предприятия сильно разрастается и уже невозможно совместить в одном человеке все необходимые компетенции с достаточной глубиной для снижения зависимости от наемных сотрудников. Более того, обычно хороший технарь - плохой менеджер.

И поэтому часто бывает, что сроки по выпуску нужного бизнесу функционала сильно просрочены или сделали совсем не то, что нужно для бизнеса, но абсолютно невозможно найти ни виноватых, ни причину происходящего. Случалось вам наблюдать такое?

Предприниматель начинает искать схемы давления на IT-отдел, чтобы хоть как-то заставить их работать на результат. Но это всегда заканчивается плохо. Падает качество, разработчики начинают выкручивать руки - просить повышения не за достижения, а чтоб хуже не стало. Появляется система бесконечных согласований, как способ ухода от ответственности. Отношения с техническим директором портятся, а уволить его реально страшно. Как вам зарплата техдира в 700 тыс руб при его практически нулевой ответственности за бизнес-результат? И это реальный пример.

Дело в том, что реальная причина - сломанный телефон между владельцем IT-продукта и разработчиками этого IT-продукта. Низкий уровень доверия между бизнесом и разработкой приводит к тому, что разные выделенные роли обдирают команду, забирая ответственность. Аналитик, тимлид, менеджер проекта, архитектор - все эти ребята оставляют команде только одно: писать код. В этой системе нет ни одного человека, который бы персонально отвечал за бизнес-результат.

Но у нас Agile! В каждой команде разработчиков есть Product Owner. Значит причина в чем-то другом, скажете вы. Давайте разберемся, кто такой владелец продукта. Это сотрудник компании, который отвечает за какую-то функцию, выполнение которой требует автоматизации. Например, владельцем продукта “1С Бухгалтерия” является главбух, владельцем CRM-системы - руководитель отдела продаж.

Представьте прямо сейчас тот функционал продукта, с разработкой которого у вас возникают проблемы. И дайте себе ответы, только честно. Какой бизнес-результат нельзя получить без него? Кто отвечает за этот бизнес-результат? Кто в иерархии находится между ним и разработчиками? Роли всех этих людей - причина ваших проблем с этим функционалом. Мы вроде бы нанимали в штат профессионалов, которые должны работать на бизнес-результат, но получили в штате безответственных узких специалистов, которые могут только писать код.

Решение в том, чтобы радикально сблизить бизнес и разработку, передать ответственность за бизнес-результат в команду разработки. В отличие от проектного аутсорсинга разработки, здесь нет реальных причин для низкого доверия. Для владельца IT-продукта это означает выйти из зоны комфорта и стать частью IT-команды на время разработки соответствующего функционала.

Но надо быть готовым к текучке кадров. В результате длительного существования иерархии в разработке остаются только такие разработчики, которым не хочется отвечать ни за что, кроме “своей” работы - писать код. Люди начнут увольняться, надо будет набирать других.

Также надо быть готовым к открытому и скрытому саботажу. Если поменять роли, но оставить людей, то эффект выученной беспомощности сведет на нет все ваши усилия по орг трансформации. Нужен профессиональный Agile-коуч или Scrum Master, который поможет вам правильно измерить и проконтролировать необходимый бизнес-эффект от орг изменений.