четверг, 1 октября 2015 г.

[prog.process.flame] Особенности разработки, про которые не хочет знать эффективный менеджмент

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

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

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

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

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


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

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

Кроме того, есть еще и вопросы психологической совместимости: бывает, что два человека с трудом находят друг с другом общий язык и определять их в одну команду нельзя, т.к. продуктивной работы у команды не получится.

Специализация бывает техническая. Так, дорого пересаживать JavaScript-разработчика на задачи server-side. Но есть и не менее важна прикладная специализация. Дорого пересаживать Java-разработчика, годами занимавшегося платежными системами, на разработку инструментов для статистической обработки данных и построения отчетов, пусть даже он продолжит программировать на Java.

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

Поэтому нельзя смотреть на имеющихся в вашем распоряжении людей как на пул ресурсов, мол у меня 80 голов, из них сейчас 15 свободно, поэтому 10 я отдаю на проект X, а 5 на проект Y.


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

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

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

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

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

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

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

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


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

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

В результате, когда из отдельных кусочков в разработке таки склеивается мозаичная картинка, то выясняется, что не нужны были вопросы про X и Y, а все это часть одной и той же фичи Z, которая уже есть в новой версии продукта. И вопрос, собственно, должен ставиться о том, как продать клиенту новую версию и провести безболезненное обновление софта и баз данных. А вовсе не о том, как делать кастомные фичи X и Y в древней версии, которая уже несколько лет как находится в режиме "только багфиксинг".

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


Предсказание сроков для новой разработки -- это соревнование в степени оптимизма.

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

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

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

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

Ну и да, планирование по контрольным точкам? Не, не слышали.


Нельзя управлять процессом разработки удаленно.

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

Такое управление скорее похоже на расстановку галочек и отсечек на план-графиках + написание писем + телефонные звонки.

Все это может работать на уровне проекта целиком. Но только не нужно путать управление проектом и управление процессом разработки.

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

Поэтому нормальный ПМ должен быть либо в шаговой доступности от своей проектной команды, либо же между ПМ-ом и проектной командой должен быть еще кто-то, кто координирует непосредственно разработку. Называют этого человека по-разному: где то это проджект-лид, где-то координатор, где-то технический менеджер, где-то скрам-мастер (если разработка идет по SCRAM-у), где-то это может быть просто тим-лид, если проект небольшой.

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

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


Привнесенная извне бюрократия увеличивает издержки, удлиняет сроки, уничтожает нормальную рабочую атмосферу и разрушает устоявшиеся рабочие связи.

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

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

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

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

Зачем действовать по принципу "Мы теперь большие, поэтому должны работать иначе"? Ведь нигде на местах нет ошущения, что работа застопорилась и нужно что-то менять. Нет, изменения происходят, но происходят постепенно и приспособление к ним идет естественным образом. Правила должны вводится, когда на низких уровнях возникает ощущение, что изменение в процессах необходимы, а иначе будет худо. Т.е. действовать нужно по принципу "Давайте уточним и подправим правила, т.к. уже нужно работать иначе".

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

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

Здесь немного дополнительной информации на тему бюрократии, тотального контроля и убийства инициативы.


И продуктам и людям нужно развитие. А это долгосрочные вещи, которые вступают в противоречие с краткосрочными планами и целями.

Любое техническое решение, принятое сегодня, каким удачным оно не является сейчас, неизбежно устареет.

Какой бы классный, компактный и красивый код не был написан сегодня, спустя 5-10 лет он очень сильно изменится.

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

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

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

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

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

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


Стоимость менеджеров так же входит в стоимость разработки.

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

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

И можно сколько угодно кричать о том, что разработка слишком дорогая, а сроки излишне раздуты, при этом приводя кучу обоснований (отсутствие формальных процессов, неразбериха, некомпетентность, отсутствие взаимопонимания, саботаж и самоуправство)... Но когда на ЗП одного менеджера в Москве можно содержать целый отдел в Гомеле (а на ЗП кого-нибудь из директоров даже несколько отделов), то снизу причины дороговизны разработки выглядят совсем не так, как сверху.


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

Боюсь, моя разговорчивость в очередной раз до добра не доведет :) И будет использована против меня, если мне придется искать работу менеджера в какой-нибудь большой и солидной компании ;)

Отправить комментарий