×

«Думать — трудная работа», или 3 причины неудавшихся проектов

Crash image via Shutterstock.

[От редакции: автор, приславший данную статью, пожелал остаться анонимным]

В этой статье я расскажу о трех основных причинах, приводящих к провалу проектов.

Рассмотрим «кейс из жизни». Он содержит острые углы, удары о которые я наблюдал неоднократно, и идеально подходит на роль модели для дальнейших рассуждений.

Кейс

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

СТО из А осознает важность знаний, и потому назначает своих подчиненных Майкла и Стива перенять знания у Васи, Пети и Коли. Майкл и Стив понятия не имеют, что такое 100% знаний, и верят украинской команде на слово.

Вася, Петя и Коля проводят knowledge transfer за 3 дня, затем подписывают все необходимые бумаги и исчезают в неизвестном направлении с намерением красиво пожить на заработанные деньги.

10 декабря 2999 года. СЕО из «А» по всем правилам SMART ставит перед СТО задачу развернуть к 01 июля 3000 года «купленное сокровище» внутри корпорации. Для этого СТО должен уложиться в бюджет $500 000 и провести интеграцию с существующими системами учета кадров и рабочего времени .

СТО, сидя вечером со стаканом чего-то, намечает в голове план действий:

  1. 01 января — 01 февраля — провести тендер между 5 компаниями-разработчиками (вендорами);
  2. ... потребовать план от вендора;
  3. 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»

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




14 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

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

Хорошо написано. В будущем предлагаю соавторство в первых двух заявлных темах. Взгляд дизайнеров ))

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

На самом деле проблема-то в самом фундаменте. Вася и Петя придумали «кой-чего». А в ответ на это получили деньги. Если бы взамен они получили совсем немного денег (грубо говоря себестоимость), + долю проекта — вот хрен бы он тогда провалился!!! Потому что именно эта роль [владелец доли] позволяет иметь обратную связь вопреки всем корпоративным правилам.

Именно так обратная связь работать и должна. Она не может работать по иерархии, поскольку на каждом звене информация пройдёт столь знакомое преобразование: ложь -> наглая ложь -> статистика.

Думать не сложно. Рисковать — вот что сложно. И как только отвественность будет передана «козлу отпущения», и как только вы услышали это самое «да, мой повелитель» — считайте проект уже проваленным.

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

Риск — самая оплачиваемая работа в мире! А думать — эт каждый может, даже индюк.

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

Черт побери. Узнал себя.

Красиво написано! Типичный пример того, как пишутся 90% статей на всяких сайтах по менеджменту! Сформулирована какая-то абстрактная ситуация, выдумана из воздуха проблема и предлагаются варианты ее решения. А по сути ничего не понятно.
Без конкретики одна вода получается.
В общем, нужны подробности — что за система, где и как внедрялась, с какими трудностями столкнулись, насколько был превышен бюджет и сроки, был ли завершен проект — тогда получится хороший кейс для разбора.
Почитайте, к примеру, Ашманова «Жизнь внутри пузыря».
Он вроде бы тоже не раскрывает всех деталей, но читать интересно и вполне жизненно получается. Я прочитал все зараз, хотя там много страниц.
www.ashmanov.com/pap/bubble

Или почитайте это: www.happy-pm.com — там тоже много интересных кейсов разобрано.

Рецепта все равно нет. Можно работая на 15 проектах с одними и теми же действиющими лицами к 3 проекту отработать как и что делать, чтобы было максимально эффективно. Но стоит поменять любой из элементов системы (команду, заказчика, и тп) — единственный выход — пробовать, спотыкаться и пробовать. Единственная методика — «наступать на грабли пока не набьет шишку». Причем избежать грабель не выйдет все равно. Они всегда будут то другог оцвета, то формы.. Единственная превентивная мера — сразу всем действующим лицам собраться и высказать все свои предположения. А поскольку последнее больше подходит для сеанса групповой терапии, а не для работы, то можно хотябы попробовать чтобы кто-то один сообщил остальным, что просто бывает только в сказке, и что давайте-ка все сращу договоримся, как мы будем идентифицировать, трекать и митигейтить эти и другие риски.

P.S. Ну и если грабли уже надоели (а это значит опыт работы достаточный уже :) ), можно почитать какие-то книжки по риск-менеджменту в софтверных проектах.

Статья очень жизненная. Особенно про то, что «Нужно думать» и «Думать — трудная работа».
И проект хорошо расписан.
Особенно в части отсутствия ДУМАЮЩИХ людей.
Их в принципе в этом проекте нет. Есть куча прогеров, пиэмов, инвесторов...

А АНАЛИТИКИ ГДЕ???

Пи.Эс.
И почему меня не удивляет, что проекты без аналитиков играют в ящик? :)

Понравилось, кратко и по делу.

Упомянул Agile вроде зачет, но упомянул как -то без благоговения .....

Эта цитата из Библии — самое удивительное, что я узнал за сегодня

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

Підписатись на коментарі