Кто виноват в переработках?

(Из ленты 255 ступеней)

Slow down, you’re doing fine,
You can’t be everything you want to be before your time.
Although it’s so romantic on the borderline tonight.
But when will you realize… Vienna waits for you?

(Замедли свой бег, все в порядке,
Ты достигнешь всего, когда время придёт,
И пусть на границе сегодня романтика,
Когда ты поймёшь, что… Вена все ещё ждёт?)

Введение

Во время спора об уместности переработок некто под ником bsod предложил гипотетическую ситуацию http://forums.software-testing.ru/index.php?showtopic=7117 :

Не готов согласиться в том, что переработки — это в 99% недосмотр менеджмента. Думаю, в 50% только. В остальных 50% — происки конкурентов.

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

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

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

Действия топ-менеджмента? Посмотрели на фичу клиента и поняли, что фича-то зиждется просто на гениальной идее. Которая, вау, еще не запатентована. Которую задевелопить-то всего командо-неделя. Ну и две командо-недели потестить. Что дальше? Смириться с тем, что у нас процесс и план, в котором нет такого риска? Соответственно и рыпаться не будем? Будем смотреть как конкурент перетягивает клиентов? Или все-таки поборемся? Надо только поработать побольше. Может пару ночей не поспать. Кстати, задержать выпуск на три недели тоже нельзя — у вас ведь еще OEMы, VARы, partner’ы и прочие reseller’ы, у которых печатные станки раскочегарены, и которые могут вас поставиь на некислые бабки в случае задержки релиза даже на неделю.

Извините, задело. И прошу прощения за слог. Есть все-таки места, где приходится перерабатывать, просто чтобы успеть за конкурентами. Рынок диктует свои условия. Конкуренты не спят, а тоже работают. И далеко не всегда по 40 часов в неделю…

Ну что ж я поднимаю перчатку и продолжаю спор.

Предположим это так

Пусть есть фирмы А , Б и В. (Гении, планировщики и торопыги)
У каждой примерно по 20% рынка. Фирма А анонсирует бету с «гениальной фичей».
Допустим, реальных альтернатив у фирм «Б» и «В» всего две: продолжать работать по плану или «поднапрячьмся» и успеть реализовать таки эту гениальную фичу к заданной дате.

Пусть, планировщики приняли решение выпустить то что предполагалось изначально. Спокойно довести софт от сырого состояния до стабильного и осуществить поставку. Одновременно анонсировав, что подобная фича появится в ближайшее время. После чего, или лучше одновременно, запустить проект по подготовке патча. Исходя из условий задачи: через месяц выходит стабильный релиз без фичи и еще через месяц – патч.
Фирма «В» (торопыги) решает поднапрячься.

Через месяц для планировщиков настают тяжелые времена. Часть их клиентов задумывается о переходе на альтернативные варианты. И часть даже переходит. Часть ждет. Если вы посмотрите статистику распределения пользователей, то увидете, что 5-10% относится к сегменту рисковых первооткрывателей. Они спрыгивают с состава «Б» и уходят к конкурентам. Пусть это 10%. Половина уходит к «А», половина к «В». Расклад рынка через месяц:

• А – 21%
• Б – 18%
• В – 21%

Через месяц выходит патч и ситуация стабилизируется. Фирма «Б» проиграла?

Поживем — увидим. Фирма «А» нам более не интересна, последим за борьбой между «Б» и «В». Благодаря скорости торопыги вырвались вперед, но делать ПО в спешке сложно и, естественно у клиентов полезли ошибки. Срочно нужен патч. Но напряженная работа существенно снизила производительность команды. Оправиться от последствий переработки непросто и патч выходит через два с половиной месяца. За это время 5% рисковых пользователей решает вернуться к планировщикам. Соотношение стало 19% у планировщиков на 20% у торопыг. А в это время планировщики спокойно готовят новый релиз с кучей новых «гениальных» фич. И выпускают этот релиз на 3-4 месяца раньше. Торопыгам тяжело догнать планировщиков, т.к. кроме того, что в спешке делается не просто глючный софт. В спешке делается софт неустойчивый к изменениям. И еще 5-10% пользователей покидают торопыг. Счет сравнялся.
С каждым кварталом торопыги будут терять все больше и больше клиентов. Ну а теперь подобьем бабки:

• У торопыг чуть больше денег в краткосрочной перспективе
• У торопыг подмоченная репутация
• У планировщиков устойчивый рост рынка за счет торопыг (на мой взгляд, в течении года)
• У торопыг разбегается команда

О последнем надо сказать особо. Один из методов уничтожения команд выявленный Томом Демарко и Тимоти Листером – это как раз переработки. Действует даже более эффективно чем изощренная система мотивации или плакаты «Наша цель – качество / Люди наш самый ценный ресурс / …» (подробнее смотрите «Peopleware»). По статистике Йордана в первую очередь уходят лучшие. А вот неудачники склонны оставаться.

Если сотрудники организации увольняются, то кто уходит в первую очередь? Самые продуктивные! … В результате их ухода средняя продуктивность организации падает еще больше, что вызывает дальнейшее ухудшение морального состояния, … которое повышает текучесть кадров … и так до тех пор, пока в организации не останутся одни зомби из фильма «Ночь живых мертвецов». (с) Эдвард Йордан «Путь камикадзе».

Моя статистика подтверждает эти выводы.

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

А как на самом деле?

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

Но посмотрите статистику. Сколько продуктов выходит без всяких гениальных фич, которые есть у конкурентов. Выходят на занятый рынок. И отвоевывают себе место под солнцем. Ну, совсем элементарный пример: MSSQL и Oracle. Или если хотите рассматривать российский рынок, возьмите войну бухгалтерий лет десять назад. Инфинбухгалтерия была лучше, чем 1С. Да что там! 1С – была одним из худших продуктов. Ну и посмотрите на рынок сейчас.

Приведу пример из моей практики. Коробочный софт, порядка трех тысяч потенциальных клиентов. На рынке, кроме нас еще 3-4 игрока. Наш софт лучший. Но вдруг выясняется, что нужно реализовать еще пару фич и успеть надо обязательно к определенной дате. Напряглись, сделали. Думаете, клиенты выстроились в очередь и расхватывали программу как горячие пирожки? Как говорил герой одного известного анекдота: «Ну да, конечно». К счастью, в сумме переработка получилась не очень большой. Что-то около 40 часов за месяц.

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

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

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

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

Попробуем найти оправдание переработке

И все-таки в этом что есть. Не может же миллион мух ошибаться

Придумаем гипотетическую ситуацию.

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

Совещание.
Действующие лица [1]:

• Генеральный директор
• Менеджер продукта
• Архитектор
• Заказчик

Архитектор. Это очень жесткий срок и риск срыва сроков очень велик.
Заказчик. Я понимаю. К сожалению, нам срочно нужен этот продукт.
Генеральный Директор. Вы могли бы обратиться к нам на полтора месяца раньше и тогда бы этой проблемы не было.
Заказчик. Это полностью наша вина. Я не буду проводить здесь анализ причин проблемы и прошу вас сосредоточиться на возможностях решения.
ГД. Сокращение сроков в два раза приводит к резкому удорожанию проекта, ухудшению качества и очень серьезно увеличивает риски. По моим прикидкам прибыль за полтора выигранных месяца должна минимум на порядок превосходить первоначальную оценку стоимости проекта.
ГД. У нас есть маневр по объему работы?
Менеджер Продукта. Есть, но он очень невелик, и учитывая криптрикваемент (расползание требований), он явно недостаточен.
ГД. У нас есть маневр по реализации?
А. Есть. Но совершенно очевидно, что не продукт одного дня. Мы уже сейчас планируем его дальнейшее развитие и выпуск следующих версий. А попытка просесть по такому показателю, как «расширяемость» означает, что никакой рефакторинг нам не поможет. При производстве следующей версии весь код и сопутствующие артефакты нужно будет выбрасывать на помойку. А это 50-80% стоимости первого этапа.
А. Можно просесть по качеству, но опять же в дальнейшем это приведет к труднопрогнозируемым и наверняка неприятным последствиям.
ГД. Ну что ж общее резюме такое. Шанс успеть – минимален. Более того, попытка успеть раньше может легко вывести нас на срок в 4-5 месяцев вместо трех. И почти наверняка будет задержан выход следующей версии.
З. Господа, я готов разделить ответственность за риск срыва сроков. В свою очередь, готов увеличить стоимость проекта в полтора раза вне зависимости от сроков реализации и предложить дополнительно премию при сроке в полтора месяца.

Заметим, что в сложившейся ситуации виноват кто-то из топ менеджмента заказчики, отвечающий за портфель проектов организации (см. Том Демарко и Тимоти Листер «Управление рисками»). Но заказчик взял вину на себя и готов пойти навстречу проектной команде для ослабления проблем. Риски велики, но и приз хорош. Кроме того, с самого начала складывается дружественная, благоприятная атмосфера проекта. В результате мы имеем безнадежный проект класса «Миссия невыполнима». Можно играть? Можно. Но по нашим правилам.

Начинаем считать резервы:

• Назначение куратором (менеджером проекта) офис менеджера организации [2].
  Если понадобится пицца для проектной команды, задерживающейся вечером, то нужно просто сообщить об этом куратору. Если понадобится «тихая гавань», то нужно просто сообщить об этом куратору. Если понадобится машина, для путешествия к заказчику, то нужно просто сообщить об этом куратору. Если проектную команду кто-либо попытается побеспокоить, то заниматься этим будет куратор, а команда будет продолжать заниматься проектом. Если команде понадобится эксперт по технологиям, то искать этого эксперта будет куратор, а команда будет продолжать заниматься проектом.
• Менеджер продукта собирался с семьей в отпуск через месяц. Это совершенно нормально, что человек ответственный за продукт отсутствует в середине проекта. Но не в данном конкретном случае. Организация готова взять на себя компенсацию за срыв личных планов.
• Несколько человек из команды собирались пройти тренинги в этот период. От тренингов придется отказаться. Это скажется в долгосрочной перспективе и ухудшит мотивацию сотрудников. Соответственно, организация готова предоставить возможность прохождения тренингов по выбору сотрудников, но только после завершения проекта.
• Следующая неделя – этап завершения ранжирования требований. Больше времени давать нельзя. Но этого мало. Соответственно, заказчик готов отстранить от повседневной работы специалистов по предметной области и предоставить их в полное распоряжение аналитиков. Компенсацию за это заказчик берет на себя.
• Заказчик согласен, что можно будет выкинуть любую малоценную функциональность.
• Генеральный директор переводит команду в режим изоляции. В помещении отключаются телефоны.

Можно еще поискать резервы, но сверхурочные среди них отсутствуют. На них ставку не делают. Спурт возможен только на две недели. И работа в «бункере» будет введена, только в самом, самом крайнем случае.

Причины переработок

Йордан приводит свой список причин участия в безнадежных проектах. Я приведу свой список причин переработок, которыми руководствуется руководителя проекта:

• Желание выслужиться
• Недостаток авторитета и силы воли для противостояния в политических играх
• Попытка «ударным» трудом скрыть свою некомпетентность в планировании, анализе и проектировании

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

Заключение
Готов ли я участвовать в «Невыполнимой миссии»? Вы знаете, да. Здоровый дух авантюризма не до конца умер во мне. Но если переработки становятся нормой, то может быть что-то поправить в консерватории?

——————————————————

[1] Вас может удивить отсутствие менеджера проекта. Доказывать в этой статье целесообразность отсутствия выделенного менеджера проекта я не буду. Это тема отдельной, даже не статьи, а книги. Просто поверьте на слово, что сработанной небольшой команде помещенной в благоприятную рабочую среду, выделенный менеджер проекта не нужен. К сожалению, искусство создания таких команд и такой атмосферы на постсоветском пространстве почти утеряно. Так что считайте, что вам столкнуться с такой ситуацией не придется.

[2] Неожиданное на первый взгляд решение. Обоснование роли такого «завхоза/менеджера по внешним связям» можно найти в романе «Проект Венера» (другое название «Торговцы космосом») Фредерика Пола. Кстати, очень неплохое описание проекта «Миссия невыполнима».

Источник: Кто виноват в переработках?