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

Если за проектом стоит умный клиент с адекватным пониманием сроков, цены и порядка работы – его надо делать. А как понять, какого калибра проблемы впереди? Что сделать чтобы минимизировать сложности? Сколько денег брать и как работать?

В этой статье я постараюсь суммировать реальный опыт, который мы получили в нашем крупном и высокорисковом проекте Домино.рф

Статья подготовлена почти год назад и местами даже нам (мне и моему соавтору Алексею Шкарупа) кажется наивной.

Тем не менее многое из написанного актуально для большинства компаний и проектов.

Итак.

Как определить большой проект?

Что такое большой проект? Чем он отличается? Чем опасен и чем интересен?

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

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

Мы сформулировали ряд признаков:

• запуск ведется в несколько этапов. 

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

• проект превышает предыдущий более чем в два раза.

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

• в основе проекта новая, необкатанная идея или технология.

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

Особенности большого проекта

• Крупный проект — всегда политика 
  
  Крупный сайт, веб-проект, автоматизация всегда меняет логику работы бизнеса. Это всегда революция. 

  А значит, будут люди, которые пострадают от внедрения, которые НЕ заинтересованы в запуске проекта. 

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

• Неопределенность требований и разброс оценок 

  Поймите: Клиенту в начале проекта очень страшно. Страшнее чем разработчику.

  Нормального ТЗ нет. Сроки все говорят разные. Суммы отличаются в десятки и сотни раз. Коммерческие предложения все на одно лицо. Личные рекомендации не спасают: даже самую лучшую компанию кто-то один обязательно ругает.

  А у зама по коммерции «есть проверенные ребята» и сын там работает. Очень страшно.

• Интеграция с внешними информационные системы и встраивание в бизнес-процессы клиента - особый и большой риск

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

  Как сказал однажды знакомый специалист по внедрению бухгалтерских систем: «чтобы это запрограммировать, нужны одни деньги, а чтобы оно потом заработало — другие». 

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

В проекте Домино было так:

ТЗ на 6 листах было разослано в 100 ведущих компаний веб-разработчиков страны. Оценили его в сумму от 30 тр до 2 млн.

Как выбрать – неясно. 

Нас выбрали потому, что:

• у нас хорошая репутация;
• офис в 1 км от клиента;
• мы твердо говорили что в проекте масса проблем, и мы знаем как их решать. 

Но директор, разумеется, хотел знать цену и срок четко.

Четкий ответ мы дали. До того, как написали финальное ТЗ в 100 страниц.

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

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

Вопросы клиента

Вообще говоря, клиент и разработчик — почти равноправные стороны процесса разработки, и риски у них схожие. 

• цель и задача 

  Нужно понять зачем создается проект. Прибыль? Слава? Поддержка основного бизнеса? Новый рынок? 

  Как результат будет проверяться? 

  Какие сроки? понятно, что «вчера», а реально какие? 

  На эти вопросы нужно дать продуманные и максимально достоверные ответы. 

  Маркетинговые призывы вместо целей и задач проекта — плохой признак. 

• рамки и приоритеты 

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

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

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

• нагрузка на специалистов клиента 

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

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

  Неверное понимание разделения обязанностей («как, я думал это тоже вы делаете!?») — крупный риск.

  Умный и дальновидный клиент, независимо от того, вызывают у него доверие сотрудники исполнителя, обязательно спросит: «что и когда должны будем сделать мы?». Осторожный — еще и запишет это в договор.

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

  К текущему моменту контактное лицо сменилось уже дважды, а работа продолжается. Проект сдан и активно развивается нашей службой поддержки.

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

• кто будет делать и как? 

  Какого разработчика выбрать? Внешние люди или свои сотрудники? Местные или «варяги»? Коробочная система, гибкий фреймворк или оригинальный код, где «все свое»? Полный разбор этого вопроса не вместится и в десяток таких статей, скажу коротко главное.

  Своя команда это хорошо, если она у вас есть: сработанная, профессиональная, структурированная и управляемая.

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

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

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

• как быть уверенным что все получится? 

  заказная разработка крупного проекта это всегда очень рискованное мероприятие. Опрос IT-директоров журналом Intelligent Enterprise показал, что  

  - 31% проектов завершаются провалом
  - 53% проектов завершаются с перерасходом бюджета в среднем в 1,9 раза
  - 16% (всего!) проектов кладываются в срок и бюджет. 

  Согласитесь, вам бы хотелось попасть в 16%? Однако куда больше шансов, особенно при отсутствии опыта, осторожности и удачи, попасть в другие группы.

Вопросы разработчика

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

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

• распознать большой проект 

  Вовремя понять что проект новый, крупный, рискованный и увидеть свои риски, а затем понять как ими управлять.

• оценить проект 

  любым способом, которым он владеет, постараться оценить объем трудозатрат, а потом разумно применить «множители»: новая технология, слабое ТЗ, сжатые сроки, отсутствие слаженной команды, плохо проработанные ограничения.

  Вообще говоря, есть статистически проверенные методики оценки масштаба проекта PERT, CoCoMo II и другие. В чистом виде они вряд ли сработают, но полезные мысли в них есть. 

• определиться с методикой управления проектом 

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

• составить список рисков 

  И решить что делать с каждым: принять, передать, застраховаться, снизить. Главное — увидеть.

• сделать все для успеха 

  нормальный амбициозный разработчик захочет добиться результата. Вопрос — сможет ли.   

Основные риски

• неправильная оценка задачи исполнителем и слишком большое доверие со стороны клиента. 

  Плохо даже не то, что исполнитель ошибается в оценке задачи и своих сил. Плохо то, что он не понимает что его оценки очень слабо обоснованы.

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

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

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

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

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

• большие сроки и утрата контакта 
  Если разработка ведется большими этапами, к чему логично приводит попытка сделать «все сразу по большому ТЗ», в процессе работы утрачивается человеческий контакт между сторонами, многие детали забываются, заказчик устает ждать и испытывает скорее негатив чем предвкушает успех. Этот риск лежит не столько в рациональной сфере, сколько в эмоциональной, и оттого он опаснее.

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

  Этот риск в итоге угрожает не только проекту, но и отношениям между сторонами. 

  Этот риск частично реализовался в нашем проекте Домино. Мы делали его больше года, и за это время многое поменялось. На наш взгляд, лучше было запустить сначала один самый сложный раздел (например Авто), обкатать на нем общий механизм и потом развиваться. Заказчик же предпочел узнать цену и срок на «все сразу», хотя многое не было готово к такому крупному этапу. В результате было потеряно много времени, нервов и денег. 

• изменение требований и цена развития 

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

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

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

  Есть несколько способов работы с таким риском, выбор между ними зависит от проекта и от отношений клиента с разработчиком.

  Общая же рекомендация — этапы меньше, запуск быстрее.

  При плохой работе с этим риском могут быть сразу 2 последствия:

   - проект всегда готов на 90%,

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

• реальный объем данных и производительность 

  Отдельная большая задача, про которую часто забывают или делают поверхностно — протестировать проект полностью на реальном объеме данных, пользователей, просмотров; найти и устранить все узкие места в проекте.

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

Ключевой вопрос принятия решения

Какие это должны быть люди? Они должны:

• иметь опыт в таких задачах (критерий размера проекта)

• поймут идею и «загорятся» ей, захотят заниматься проектом

• зададут вам такие вопросы, которые вы сами себе не задавали

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

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

Что же касается выбор движка, CMS, платформы. Разработчик всегда что-то советует, потому что «оно самое лучшее». Для нетиповых проектов этот выбор крайне сложен, но очень важно чтобы клиент не зависел он конкретной команды.

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

Мы как разработчики всем советуем 1С-Битрикс, и вот почему.

Технология взаимодействия: идеал и реальность

• Заказчик не хочет никакого «напряга». Он хочет поставить задачу, причем не техническим языком, а языком бизнеса.

• Он хочет что разработка велась быстро и без ошибок, а результат удовлетворял всем требованиям, в том числе и не высказанным явно.

• Заказчик всем видам общения предпочитает телепатию и склонен во всех ошибках понимания винить Исполнителя.

В его логике все верно.

Исполнитель настроен совершенно иначе. 

• Он ждет чтобы заказчик четко поставил задачу и был способен быстро давать ответы на специфические вопросы. 

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

• Исполнитель всем видам общения предпочитает бумажное подробное непротиворечивое задание, желательно написанное для него или даже самим исполнителем. 

• Решение всех проблем взаимопонимания такой разработчик видит лишь через поиск соответствующего пункта в ТЗ.

В его логике все верно.

Налицо противоречие в приоритетах и предпосылки для конфликта.

• Заказчик редко готов дать ту информацию, которая объективна нужна для проекта. Меняется не только техническая сторона требований, но и понимание бизнес-результата. Часто в ходе проекта в самый непредсказуемый и неудобный момент меняются ключевые сотрудники заказчика.

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

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

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

• А сроки в крупных проектах почти всегда срываются.

Часто противоречия приводят к конфликту.

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

В нашем проекте Домино реализовались в полной мере риски замены контактера, интеграции с внешними системами, риск длинных этапов и накопления изменений и частично — риск большого ТЗ. 

Оценка и планирование проекта

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

Если же бумажного внятного документа с описанными ограничениями нет, стоимость смело можно брать «с потолка»: все равно ошибетесь.

Это объективная реальность, что вначале проекта никто не знает его стоимости и сроков запуска. Существующие научно и статистически обоснованные методики крайне слабы и на практике малоприменимы.

Что же можно сделать чтобы проект получился (интерес заказчика) и принес прибыль (интерес разработчика), а сроки уложились в отведенные рамки (всем хочется):

• грубая оценка с запасом и детальный план 

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

• сначала ТЗ, потом оценка 

  Можно заключить отдельный договор на написание детального ТЗ. Это стоит 10-30% цены самой разработки. Проблема в том, что клиенту обычно не нравится что он оплачивает ТЗ, которое, на его взгляд, нужно только разработчику. Кроме того, большое и подробное ТЗ это само по себе отдельный риск.

• разработка небольшими порциями 

  Этот подход становится все более популярным. Разработка ведется небольшими порциями длительностью от 2 недель до 3 месяцев, задания на которые не очень большие. Оплачивается каждая порция, каждая порция запускается и расширяет возможности проекта. Технология хороша тем, что у клиента всегда есть продукт, которым можно пользоваться. Нет многих рисков: потери контакта, большого ТЗ, отсутствия тестирования. Есть и минусы: никто не знает сколько порций потребуется, какая будет в итоге стоимость и срок разработки. Клиенту часто это не нравится. 

  Впрочем, это симметрично: разработчик никогда не знает всей задачи, что часто ему не нравится.

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

Договор и правила игры

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

По недавно опубликованному исследованию, 30% сайтов делаются вообще без договора.

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

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

• Хорошие вещи делаются не по договору. Хорошие вещи можно сделать только при человеческих отношениях. Договор это страховка на случай проблем.

Не нужно автоматизировать бардак

При проектировании сайта, продумывании интерфейса, логики и деталей нормальный аналитик, менеджер будет предлагать свои варианты. Упростить логику, изменить последовательность шагов, пересмотреть правила.

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

Почему это происходит? Сторонний аналитик это «свежая голова», которая видит не совсем логичные или не единообразные элементы проекта и может предложить свое.

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

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

Крупный проект это и экономика, и политика

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

Документирование задачи

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

Документы это не панацея, и универсального рецепта тут нет. В чем специфика крупного проекта:

• много информации
• сложность высокая
• детали вначале неизвестны, а потом идет уточнение.

• краткая постановка задачи в договоре. 6 листов текста, где указаны ограничения: не более 30 типов объявлений, не более 10 форматов файлов обмена, не более 300 полей во всех формах ввода данных. Эти ограничения очень важны

• собственно техническое задание мы делали на базе Axure, где создавались живые кликабельные макеты, несколько диаграмм, документирующих смену состояний объявлений

• текст ТЗ писался, читался, обсуждался в google docs

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

Отслеживание процесса разработки

• диаграмма Гантта, где надо отмечать реальные и фактические сроки

• багтрекер, куда имеет ограниченный доступ и закачик

• регулярные встречи с клиентов (особенно если проект делается одним огромным куском) 

Что было бы крайне полезно, но к сожалению мы не сделали этого

• неизбежные изменения в ТЗ, вызванные исправлением ошибок, уточнениями (например, добавили частному дому поле подвал) надо фиксировать в листе изменений. У нас они оказались разбросанными по почте.

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

Сдача проекта. Нагрузочное тестирование. 

Расскажу на примере Домино:

• прямо в договоре мы записали требования к работе сайта на разделяемом хостинге: 200 тысяч просмотров в сутки (примерно 3 просмотра в секунду), среднее время генерации страниц до 0.5 с, доля ошибок 50? не более 1%

• специфика проекта в том, что данные очень интенсивно обновляются и механизмы кеширования работают не очень эффективно

• при сдаче проекта мы провели тест (хостинг Timeweb, тариф Eterno). Среднее время генерации было около 0.2 секунд, ошибок 500 не было вообще. 200000 просмотров сайт выдержал легко

• показательно что в ходе теста было найдено около 10 узких мест в коде, потребовавших переработки. Устранение этих проблем дало примерно двукратное сокращение.

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

Парадокс больших проектов

Я считаю что делать проект как набор этапов, каждый из которых оценивается и запускается отдельно — лучшая практика. Это лучший вариант и с точки зрения планирования, и качества результата, и для бизнеса.

Для клиента обычно все доводы перевешивает единственный плюс варианта «один договор, одно ТЗ, один этап» — сразу зафиксирована дата запуска и бюджет.

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

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

Отдельно надо сказать про эту самую «дату окончания». 

Современный проект, созданный для бизнеса, постоянно меняется. И никакой финальной даты просто нет. Есть текущее состояние непрерывного изменения.

Выводы

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

• работа этапами — лучший вариант;

• обмен данными с внешними системами нужно делать и тестировать в самом начале проекта;

• работать над заданием нужно коллективно и «в прямом эфире» через Google Docs;

• большой проект это всегда политика, и он всегда существенно меняет бизнес;

• и помните: ваш следующий проект не должен  превышать предыдущий более чем в 2 раза.

И еще вывод

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

И все получится.

Оригинал: http://www.intervolga.ru/blog/thoughts/big-project-risks/

Иван Бормотов
Руководитель в Qualitica

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

В крупных проектах для Правительства Москвы мы работаем, руководствуясь следующими принципами:

• Сначала крупными мазками фиксируется общий объем работ по проекту;
• Каждую неделю проводятся встречи с заказчиком для определения приоритетов и плана работ следующей недели;
• Каждая из задач обсуждается, при необходимости согласовывается на уровне прототипов, после чего трансформируется в задачу, понятную конечному исполнителю;
• Сначала делается основной функционал — тестируется, показывается заказчику, выливается в бой;
• В ходе эксплуатации собираются и анализируются комментарии пользователей, дополняются ранее известными задачами, и все это ставится в работу. Так функционал оттачивается в боевых условиях, а не в теории на листах ТЗ;
• У заказчика есть доступ «для чтения» к системе постановки задач конечным исполнителям — при желании он может посмотреть текущие задачи и затраты на их выполнение. Это создает ощущение прозрачности в работе, помогает лучше планировать, определять приоритеты.

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

Роман Петров
Директор в Ай Ти Констракт

Отличная статья! Достаточно давно мы поняли, что большой проект сильно отличается от небольших проектов как с точки зрения рисков, так и процессом ведения и управления проектом. Финальный вывод Степана
Овчинникова можно дополнить так: "В большом проекте должен быть ответственный сотрудник, который уделяет проекту всё свое время и действительно заинтересован в успешном завершении проекта, умеет находить компромиссы и обосновывать свою точку зрения как внутри компании, так и подрядчику".
Еще, в крупной компании хорошие результаты показывает выделение нового большого проекта в независимое подразделение. В этом случае гораздо легче принимаются решения и происходят согласования проектов.

Антон Мартынов
Директор департамента разработки в ITECH.group

Для большого проекта действительно достаточно сложно определять сроки и осуществлять оценку стоимости подобного вида работ. Основными инструментами, которые позволяют более эффективно управлять таким проектом, является принцип декомпозиции + детальная проработка ТЗ на ранних стадиях проекта. А дальше — увеличение количества итераций с обратной связью от заказчика по каждому завершенному этапу. Причем длительность одной итерации не должна превышать одного месяца, в противном случае риск «бесполезности» системы значительно возрастает. Самые большие сложности возникают тогда, когда у заказчика либо нет точного представления всех бизнес-процессов, либо эти бизнес-процессы очень плохо формализованы и содержат большое количество ветвлений и нестандартных ситуаций. Нельзя начинать проект, если нет четкого описания ВСЕЙ бизнес логики.

В моей личной практике был случай, когда два проекта, примерно одинаковые по сложности и по времени реализации (около 2-х лет на каждый), завершились совершенно по-разному. В первом случае было потрачено почти полгода на формализацию бизнес-процессов, их постановку и описание. В результате было получено ТЗ объемом более 300 листов, и проект был успешно завершен через полтора года. Во втором случае проект провалился, поскольку сам заказчик не имел четкого представления о том, как должны работать основные функциональные модули, как они должны взаимодействовать друг с другом, но при этом требовал скорее начать работы по реализации. Результат оказался плачевным.

Алексей Маренков
Исполнительный директор в "Пять плюс"

Абсолютно правильная обзорная статья. Перечислены все риски, рассмотрены все проблемы крупных веб-проектов. Однако есть свои «пять копеек», которые я обязан вставить.

Конечно, основной конфликт проекта — это его понимание. Классически (и это отображено в статье) принято полагать, что этот конфликт решается техническим заданием (ТЗ). Дескать, создать такой документ — и взаимопонимание если не достигнуто, то стало гораздо ближе. Правда есть проблемы: клиенты не любят ТЗ, сотрудники устают его читать, сам документ устаревает быстрее нового iPhone. И вот тут появляется совсем другое решение. В концепции UML это называется Use Case, в концепции Scrum — User Story. А если попросту, то это именно что описание проекта языком клиента: «здесь пользователь заполняет форму», «вот тут мы показываем банеры и наши предложения», «пользователи должны добавлять друг-друга в друзья» и тому подобное. Суть в том, чтобы описать весь проект на человеческом языке. Тут уж клиенту не отвертеться, да и сотрудникам читать такой опус проще (ведь каждая формула в книге уменьшает ее аудиторию в половину; а равно как и каждая переменная в ТЗ). Такой документ можно и нужно приложить к договору и зафиксировать: меняется он гораздо реже ТЗ, детальное ТЗ можно делать постепенно на каждый отдельный блок. А главное — клиент всегда будет понимать, какой аспект системы из ранее зафиксированных он пытается изменить своими «хотелками». Ведь этот документ написан абсолютно для него понятно.

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