Я бы хотел обсудить неприятную для многих тему, а именно — ваши иллюзии. Иллюзии и убеждения относительно того комплексного процесса, который называется разработка программного обеспечения. Давайте сразу определимся, что такое иллюзия в данном контексте — это такое убеждение человека, не подкрепленное четкими научными доказательствами.
Разработка ПО пронизана такими убеждениями на всех уровнях, начиная от выбора языка программирования, переходя на технологию проектирования, и заканчивая технологией управления проектами. Интерпретация результатов результатов успешного проекта, если вы решите проверить какую-то методику на его примере, тоже может ввести вас в заблуждение, если вы не будете настроены максимально скептично. В этом цикле статей я попытаюсь дать вам несколько отправных точек для анализа эффективности той или иной методики разработки. В какой-то мере все, что будет написано далее является просто развернутым описанием основной идеи сайта programming-motherfucker.com.
Начнем пожалуй с управления проектами, как области, где поиск истины затруднен больше всего. И если хотя бы один человек, прочитав эту статью, откажется от внедрения в своем проекте Agile (в лице одной из его подметодик), то я могу считать, что время на написание этого текста было потрачено не зря.
Введение
Возможно следующее утверждение вам покажется абсурдным и непрактичным, но так и есть: невозможно точно измерить эффективность методики разработки ПО. Объясняется это просто — чтобы получить точные результаты, нам нужно запустить процесс разработки проекта одной и той же команды, на одном и том же языке, при одних и тех же управленцах, в одно и то же время. Но при разных подходах к разработке. При условии, что у вас будут средние менеджеры, знакомые с каждой из методик разработки примерно одинаково. А также при условии, что все общение будет проходить в сугубо официальном тоне и только в текстовом виде, чтобы исключить возможность влияния харизмы/нытья/мотивации менеджеров на процесс разработки. Бред? А сможете опровергнуть по существу?
Безусловно, есть вещи, польза или вред от которых очевидна, а главное доказуема. Но стоит сделать шаг в сторону и мы погрузимся в омут, где бал правит случай, где достоверность лежит в рамках статистической погрешности, а основная аргументация — бравирование личным опытом, возведенным в ранг истины. Проще говоря попадем в реальную жизнь.
Управленцы все-таки люди
И этим все сказано. Нет правда, какие основные науки изучают поведение человека? Правильно, это психология и социология. Обе существую достаточно давно, в распоряжении обеих огромные объемы информации — СМИ, история, бесчисленное число экспериментов. И тем не менее ни одна из этих наук не способна спрогнозировать поведение человека, социальной группы, нации с большой степенью вероятности, если речь конечно не идет о тривиальной ситуации.
Это было сказано к тому, что вся теория управления в конечном счете — такая же наука о людях, только еще более молодая, имеющая несколько различных школ. И, вы не поверите, но все эти подходы, зачастую противоречащие друг другу… работают! Во всяком случае, так считают адепты каждой школы. Во всяком случае, успешные проекты есть под знаменем каждой школы, а провальные можно списать на тысячу причин, не касающихся методики управления.
Этот факт должен привести нас к выводу о том, что выбор методики управления не имеет решающего значения для проекта. Тогда логично перевести взгляд от методики на человека ее использующего. Человеческий фактор — вот единственное, что может объяснить такое случайное срабатывание методики, хотя давайте будем честными, причин может быть куча — объективная нехватка бюджета, нереальные сроки, слабый уровень программистов и т.п.
За мою скромную карьеру мне приходилось сталкиваться с разными моделями управления. Был чисто бандитский вариант, когда программистам звонили и угрожали, чтобы заставить их работать. Самая распространенная модель для небольших команд — один начальник, до десятка программистов, методология как таковая отсутствует, или же присутствуют заимствования ото всюду. Стартапы — либо аврал, либо agile и производные, либо табун разработчиков, где руководитель скорее ТЗ, чем человек. Большие команды — разброд и шатание от одного отдела/команды к другому, в последнее время закрепляется все тот же agile.
При этом все эти проекты от больших до малых живут и здравствуют, а также проваливаются. Одна и та же методика, применяемая в разных проектах может привести к разному результату. Логично предположить (пренебрегая всеми остальными факторами), что результат зависит от того кто использует методику. Получится ли смотивировать команду на продуктивную работу? Насколько успешно будут проходить переговоры с заказчиком (он ведь тоже человек)? Получится ли уговорить программистов работать за призрачные перспективы? Удастся ли организовать такую атмосферу, чтобы программист сам не хотел уходить к конкурентам? Насколько верно будут рассчитаны сроки и цена? Сможет ли управляющий сформулировать требования клиента так, чтобы команда до дня сдачи не разруливала противоречия в ТЗ?
По большей части эти вопросы лежат вне существующих методик, или же использование методик в решении этих вопросов не является определяющим. Решающим моментом тут являются личные качества человека, как бы прискорбно это не звучало, и именно они могут вопреки плохо поставленной методике ведения проекта привести успеху, или же, невзирая на самый передовой project management, провалить проект.
Поэтому перед тем как оценить очередную методику разработки, переберите в памяти всех знакомых менеджеров и дайте себе честный ответ, а справятся ли они с задачей и подчиненными?
Программисты тоже люди
Надо ли говорить, в какой степени от них зависит результат проекта? Надо. Кроме очевидного уровня профессионализма в своей области, нужно понимать, что имеют значение следующие факторы:
- разброс уровня квалификации в команде — один тимлид не вытянет пятерых юниоров. Хотя нет, вытянет — мой учитель информатики смог вытянуть целых 15 человек, но на коммерческую разработку его уже не хватило
- как проходит коммуникация в команде. Среди наиболее квалифицированных программистов высок процент тех, которые теряют мотивацию, видя часовые заседания и конференции по поводу решения, занимающего несколько строчек. Среди основной массы программистов высок процент тех, которые теряют понимание цели работы в случае отсутствия часовых заседаний и конференций по поводу решения, занимающего несколько строчек.
- насколько привлекателен проект для исполнителей. Стартап по отслеживанию спутников с выдачей карты видимости конкретного спутника в том или ином регионе Земли вызовет больше энтузиазма у практически любого программиста, нежели более простой проект вида «клон воооон того сайта, с воооот такими фичами». Я нередко слышал от программистов, что за хорошие деньги они готовы клепать подобные клоны всю жизнь, однако в реальности таким могу заниматься единицы, да и тех я не считаю программистами высокого уровня. С какого-то момента бессмысленные с точки зрения пользы(но отнюдь не бессмысленные с коммерческой) проекты начинают убивать желание работать, и происходит постепенное погружение в прокрастинацию.
- насколько программисты лояльны к существующей методике разработке. Не всем понравятся ежедневные скрам-митинги. Возможна и ситуация, когда программист является приверженцем одной методики разработки, в то время как для ведения проекта выбрана другая, но тут беспокоится не о чем — ни один здравомыслящий человек не начнет вставлять менеджеру палки в колеса, чтобы доказать, что его методика самая лучшая.
Нужно больше золота
Многие проблемы можно решать деньгами, чего уж говорить о числе проблем, которые без денег не решить. Не будем рассматривать очевидный пример, когда стартап разваливается через пару месяцев после создания из-за того, что чувство голода у программистов оказалось сильнее веры в светлое будущее. Вполне очевидно, что от бюджета проекта зависит (в какой-то мере) то, насколько профессиональных программистов вы наймете. Зависит и то, сможете ли вы позволить ввести премиальную систему для оплаты инициативы разработчиков, что также подстегнет разработку.
От денег зависят и другие тонкости: сможете ли вы в критический момент нанять консультанта, позволить себе сэкономить время, купив уже готовый компонент. В случае самостоятельного бизнес проекта или стартапа именно бюджет определит сколько вы сможете потратить на рекламу и продвижение среди сотен конкурентов. История учит нас, что проекты с плохим кодом, менеджментом таки могут прийти к успеху при грамотной маркетинговой компании.
А главное, чем больше у проекта ресурсов, тем больше ошибок он может позволить себе совершить так, чтобы это не отразилось на конечном успехе.
Случайность как значимая величина
Обычно эффективность методики оценивается по результатам проекта. И тут мы можем попасть сразу в 2 ловушки — влияние случайности и субъективная интерпретация результата. Последняя сводится к тому, что люди игнорируют число проектов, проваленных при использовании выбранной методики (да и какая разница, мы ведь выяснили, что других причин хватает). Ну т.е. большинство людей игнорирует это. Т.е. вам достаточно создать любой набор практик, применить их в паре громких проектов, доведенных до конца, объединить этот набор практик в методику управления, обозвав ее громким именем.
Поздравляю, вы только что создали свою методику ведения проектов. Никто кроме пары нытиков(чье мнение все равно не будет услышано) не будет проверять насколько реально эффективна ваша методика, все будут видеть только успех ваших проектов. Поверьте, даже если ваша методика очень плоха, все равно, ввиду наличия кучи других факторов влияющих на успешность проекта, она скорее всего даст результат в каком-то числе проектов. А если ее использование приведет к провалу, то редкий менеджер скажет, что он выбрал плохую методику, он скорее будет сетовать на плохих программистов, малый бюджет, гиблые места, невменяемых заказчиков, да мало ли еще чего.
Ввиду описанной выше человеческой природы, эффективность естественного отбора среди новоявленных да и довольно старых методик ведения проектов представляется мне довольно низкой, что ставит под сомнение утверждение о том, что используемые в разработке ПО методики правда эффективны. Ведь чтобы выжить и получить распространение методика должна соответствовать всему одному требованию — не мешать настолько сильно, чтобы завалить процесс разработки.
Пятиминутка субъективности
Сколько-либо систематизированная разработка софта идет уже не менее трех десятилетий, за это время так и не было представлено ни одной методики ведения проектов, которая была бы безоговорочно принята отраслью. Имеет место регулярная смена методик без кардинального изменения в эффективности разработки и качества выпускаемого ПО.
Заметные результаты от применения методики можно свести к ситуации, когда в команде посредственный менеджер, и любое улучшение, даже самое очевидное, может привести к улучшению. В случае среднего уровня менеджера и выше эффективность методики вообще находится вне рамок доказуемости.
Пикантности добавляет тот момент, что обычно решение о введении/смене методики разработки принимается в момент, когда становится ясно, что разработка идет неудовлетворительно. Эта мысль доносится до менеджеров и программистов, с намеком на то, что работать нужно продуктивнее, и методика выступает лишь символом. Проще говоря, основной результат получим от давления на разработчиков.
Влияние методики разработки тонет среди влияния остальных факторов, так что оценить пользу от нее в принципе не представляется возможным.
Ввиду того, что в реальных условиях не представляется возможным проверить эффективность какой-либо методики управления, мы имеем множество подходов, применяемых фактически наудачу. Все это привело к появлению целой плеяды менеджеров, спутавших принципиальную недоказуемость и сложную доказуемость (считая, что любая комплексная система правил управления просто не может быть ошибочной), и принявших решение выбрать какую-либо методологию и принять ее на веру. Со стороны это выглядит как цирк, где одни пытаются прикрыть недостаток опыта управления формальным подходом, используя модную методику, другие имея талант управлять, но не имея критического , принимают свои успехи за успехи методологии, особняком стоят менеджеры компаний, которые вносят изменения в процесс ведения проекта с целью имитации деятельности. Все это как-то существует и работает, и скорее всего будет существовать еще долго, ведь там, где нету четких критериев оценки, можно доказать что угодно.
Заключение
Если перед вами встала необходимость использовать модную методику ведения проектов, ли вам просто захотелось попробовать что-то новое, то не воспринимайте всерьез заверения о ее эффективности. Как правило признание эффективности упирается в одного-двух авторитетов, а дальше идет по инерции, и вы никогда не узнаете что же на самом деле сделало руководящую карьеру этих авторитетов успешной. Однако быть в курсе имеющихся методик следует быть, как минимум, по двум причинам — если вы хотите найти работу, и если вы хотите иметь в голове набор типовых решений для распространенных проблем. А умение подбирать шаблоны по назначению придет только с опытом.
Автор: PerlPower
