Crash image via Shutterstock.[От редакции: автор, приславший данную статью, пожелал остаться анонимным]
В этой статье я расскажу о трех основных причинах, приводящих к провалу проектов.
Рассмотрим «кейс из жизни». Он содержит острые углы, удары о которые я наблюдал неоднократно, и идеально подходит на роль модели для дальнейших рассуждений.
Кейс
Программисту Васе приходит в голову гениальная идея — создать очередную социальную сеть. Он умеет делать бэк-энд, но не умеет фронт-энд. Вася идет к Пете, знающему HTML5, и к Коле, знакомому с Photoshop. Вместе они на коленках пишут симпатичное веб-приложение. Звезды и фаза луны совпадают, и детище программистов покупает некая американская контора «А».
СТО из А осознает важность знаний, и потому назначает своих подчиненных Майкла и Стива перенять знания у Васи, Пети и Коли. Майкл и Стив понятия не имеют, что такое 100% знаний, и верят украинской команде на слово.
Вася, Петя и Коля проводят knowledge transfer за 3 дня, затем подписывают все необходимые бумаги и исчезают в неизвестном направлении с намерением красиво пожить на заработанные деньги.
10 декабря 2999 года. СЕО из «А» по всем правилам SMART ставит перед СТО задачу развернуть к 01 июля 3000 года «купленное сокровище» внутри корпорации. Для этого СТО должен уложиться в бюджет $500 000 и провести интеграцию с существующими системами учета кадров и рабочего времени .
СТО, сидя вечером со стаканом чего-то, намечает в голове план действий:
- 01 января — 01 февраля — провести тендер между 5 компаниями-разработчиками (вендорами);
- ... потребовать план от вендора;
- 01 июля — накрыть торжественный фуршет и ожидать награду за выполнение поставленной задачи.
На следующее утро СТО приходит с этим планом к СЕО. В это утро звезды и фаза луны оказываются не совсем подходящими. Поэтому, несмотря на все потраченные на бизнес-обучение часы, разговор СТО и СЕО сводится примерно к следующему:
— Сделаешь это к 01 июля?
— Да, мой повелитель.
На том и порешили.
На выборы вендора СТО тратит два месяца, а не один, как предпологал. Наконец 25 февраля компания «А» и вендор подписывают контракт по модели TnM (заказчик платит за «время и материалы»). Проект решено вести по Agile в виде SCRUM. В договоре прописано, что будет Спринт 0 и «остальные спринты, которые мы определим потом». В роли продакт овнера выступает Стивен.
После подписания контракта на стороне заказчика:
На стороне вендора:
Результаты спринта 0:
— 100 историй в бэклоге;
— Требования по приемке — отсутствие критических дефектов;
— Внутреннее развертывание решения производит заказчик;
— Тестовое окружение будет предоставлено к спринту 3. Менеджмент посчитал это разумным, так как к этому времени разработчики успеют создать нечто, что можно тестировать.
Я не раз видел ситуацию, похожую на приведенную выше. Это похоже на яхту «Победа». Но бывалые знают «Приключения капитана Врунгеля» и заранее чувствуют «беду».
Подобные проекты поражают количеством проблем и рисков. Сторонние наблюдатели спрашивают: «Как вы могли так сглупить?» Но команда смотрит «изнутри». Менеджер пообещал завершить начатое, и на кону стоит репутация компании, бизнес заказчика, ссобственное лицо и «безопасность» рабочих мест.
3 причины неудачи
Рассмотрим 3 основных причины, которые со 100% гарантией приведут вас либо к тянущемуся бесконечно «мертвому» проекту, либо к громкому скандалу и ярлыку «не способен».
1) Недопонимание
В рассмотренном кейсе компании подписали контракт на Time and Materials, но — положа руку на сердце — СТО смог бы реализовать свой план только по Fixed Price. Он не хотел особо заморачиваться, и собирался «всё потребовать от вендора».
Кроме этого, три человека вряд ли справятся с рисками, присущими подобному проекту. Менеджеры попали в распостраненную ловушку, подписав TnM контракт с Fixed Price ожиданиями.
Никто не любит, когда от него требуют, все любят требовать от других. Именно поэтому в дальнейшем заказчика будут именовать козлом, уродом и прыщем на одном месте. Причем неоправданно.
Вы сами согласились сотрудничать с ним, составлили изначальные планы работы и сделали ошибочные предположения.
Поэтому если ближе к середине проекта вы услышите от заказчика слова вроде «проактивность», «перспектива», «мы разочарованы», «вы что, не понимаете?», то вероятно, что вы действительно друг друга не понимаете.
2) Предположения
Вот краткий перечень предположений, ведущих к печальным последствиям:
Заказчик:
- У ребят хорошая репутация. Мне их посоветовал Джим, с которым мы с детства дружим.
- Я слышал, Восточная Европа просто кишит талантами. Они там все гении.
- Я плачу деньги и могу творить, что захочу.
- Они (вендор) обязаны. Мы же снизошли к сотрудничеству с ними.
- Все мы умные люди. Поэтому проблем не будет.
Программисты:
- Мы можем работать по SCRUM.
- Мы отличные программисты.
- ПМ знает, что делает.
- Заказчик должен признать свою вину.
- Мы лучше знаем, как надо делать. Заказчик для этого нас и нанял.
ПМ на стороне вендора:
- Моя команда — звери, а сам я — Юлий Цезарь. К тому же, сверху мне помогут, если что.
- SCRUM — это то, что нужно для этого проекта. Мы все должны быть Agile.
- Заказчик заинтересован в том, чтобы проект был сдан в срок. Поэтому он сделает все, что обещал.
- Все непонятное выяснится позже. На нас это никак не повлияет.
Менеджмент вендора:
- ПМ молодец, он со всем справится. Команда хорошая. Мы в Восточной Европе, а тут все гении.
- Вроде, заказчик — серьезная контора. Должны понимать, что к чему, и чем мы тут занимаемся.
- В случае любой эскалации не стоит вмешиваться в происходящее, чтобы не навредить. Гораздо эффективнее заходить почаще и просить «все исправить».
Вспоминая Библию, приведу цитату, актуальную для всех участников: «Ибо кто из вас, желая построить башню, не сядет прежде и не вычислит издержек, имеет ли он, что нужно для совершения ее, дабы, когда положит основание и не возможет совершить, все видящие не стали смеяться над ним, говоря: этот человек начал строить и не мог окончить?»
Предположения влияют на выбор того или иного способа решения проблемы. И если вы постоили свой план на ошибочных домыслах, то окажететесь в «беде». Проект рухнет, как карточный домик.
3) Неправильное/недостаточное понимание своей роли и обязанностей
К сожалению, при разработке ПО «сумма частей» не всегда составляет «целое».
Разработчики склонны недопонимать свою роль в проекте при распределенной работе над одной и той же задачей. Если каждая команда считает, что «выполнила свой объем работ», но задача в целом так и осталась недоделанной, то обе команды «упустили то что между» ними. Чаще всего это интеграция, передача параметров, end-to-end сценарии.
Программисты программируют, тестировщики тестируют, ПМ «ПМит», и никто не пытается увидеть картину целиком. В результате заказчик не удовлетворен, и вендор вынужден доказывать, что он «не олень». Когда заказчик показывает ему пропущенные места, то для вендора признать свою неспособность их увидеть будет означать признать свою некомпетентность.
Как избежать проблем
В качестве выводов я предлагаю 5 рекоммендаций, которые помогут не допустить описанных конфликтов.
1.Всегда учитывайте, что окружающий мир динамичен. То, что не имело значения вчера, может встать во главе угла завтра.
2.Помните, что человеку свойственно быть требовательным в роли потребителя и жутким лентяем в роли поставщика. Поэтому успехов достигают те, кто побеждает в себе эту лень и «поставляет» продукт, соответствующий требованиям качества.
3.На каждое сделанное предположение прорабатывайте сценарий на случай его ошибочности. Польза:
- Подобная умственная активность не даст заржаветь мозгам;
- Вы удивитесь всему многообразию возможных комбинаций и пойдете искать оптимальные. Так вы повысите свой уровень знаний и квалификации и станете более ценным специалистом;
- Ваши умения перейдут в навыки: со временем в голове образуются «шаблоны», которые помогут вам быстро и адекватно среагировать при повторении ситуации;
- Вы увидите то, что есть на самом деле, а не то, что вам хотят показать. Если вы научитесь оценивать сложность и риски предлагаемых действий, то сможете принимать решения и нести за них ответственность.
4.Помните о принципе Win-win и напомайте об этом руководству. «Игра в одни ворота» хороша до поры до времени.
Окружающий мир динамичен (пункт 1), а потому при «игре в одни ворота» закзачик будет увеличивать свои аппетиты получить что-то «за просто так» прямо пропорционально уменьшению остатков бюджета проекта на стороне вендора. А бюджет тратится на исправление того, в чем стыдно признаваться.
5.Становитесь профессионалом, а не просто программистом, тестировщиком или ПМом.
Разберитесь, чем занимаются люди, которые стоят рядом с вами в цепочке выполнения общей задачи. Тогда вы будете понимать, где именно тестировщик «недотестировал», программист «недопрограммировал», ПМ недодумал, не до конца понял или не все учел.
Это нужно для того, чтобы наиболее эффективно распоряжаться своими ресурсами. Бессмысленно тратить на задачу в 3 раза больше времени только из-за того, что вы «не увидели» настоящее положение дел.
«Думать — самая трудная работа. Вот, вероятно, почему этим занимаются столь немногие». Генри Форд
P.S.
Приглашаю читателей высказывать свои мнения. Учту их при написании следующих статей, если изложенное ниже будет интересно аудитории.
Предположительная тематика цикла статей:
— Жизненный цикл проекта «с высоты птичьего полета»
— Роли в проекте и их взаимодействие
— Типы заказчиков и методы работы с ними
— Это страшное слово «Enterprise»