Эта статья была написана после серии докладов на семинарах нашей компании, которые показали что тема крайне интересна многим специалистам и заказчикам. Надеемся, и вам понравится. Будем рады комментариям. Соавтор статьи — Алексей Шкарупа, менеджер проекта Домино.

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

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

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

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

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

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

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

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

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

• Неопределенность требований и разброс оценок
  В этом блоке будем говорить о рисках клиента.
  Большой проект потому и большой что в нем много нерешенных вопросов.
  На начальном этапе задача обычно описана лишь в общих чертах, что совершенно понятно и нормально
  С другой стороны, при принятии решения о старте проекта и выборе подрядчика руководитель всегда хочет знать предельно точно срок и стоимость проекта.
  А такой оценки нет. Что делать?
  Распространена практика сбора предложений у разных исполнителей.
  Точность такого обзора всегда крайне низкая даже при наличии общего ТЗ.
  В итоге руководитель находится в ситуации, когда у него нет возможность выбрать разумно. Цены отличаются в десятки и сотни раз, компании-исполнители при поверхностном рассмотрении все одинаковые.

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

В проекте Домино сайт имел важное стратегическое значение для бизнеса, и уровень заинтересованности руководства был очень высокий. На самом деле это большой плюс. Первоначальное ТЗ опрошенные 50 команд веб-разработчиков оценили от 30 тысяч рублей до 2 миллионов. Такой разброс предсказуемо не давал принять решение с кем это делать. В полной мере реализовался риск интеграции с внешними системами — файлы импорта для сайта, справочники, парсер объявлений были готов на 4 месяца позже надо, и это отодвинуло запуск и потребовало в режиме ручного управления менять порядок реализации.

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

Вообще говоря, клиент и разработчик — почти равноправные стороны процесса разработки, и риски у них схожие. Какие вопросы ставит (или должен ставить) перед собой клиент, решивший сделать что-то необычное и большое — крупный веб-проект:

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

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

• нагрузка на специалистов клиента
  Часто клиент не подозревает как много работать придется ему самому. При создании крупного заказного проекта нагрузка на специалистов клиента может быть очень значительной. В нашей практике несколько раз были случаи, когда проекты сворачивались или их сроки и состав сильно менялись потому, что менеджер клиента не был готов, не мог или не хотел уделять проекту много времени и выполнять квалифицированно свою часть работы — думать, готовить информацию, принимать решения, анализировать варианты.
  Часто со стороны клиента нужен не только менеджер и оператор для ввода данных, но и разработчики, системные администраторы, маркетологи, копирайтеры.
  Неверное понимание разделения обязанностей («как, я думал это тоже вы делаете!?») — крупный риск.
  Умный и дальновидный клиент, независимо от того, вызывают у него доверие сотрудники исполнителя, обязательно спросит: «что и когда должны будем сделать мы?». Осторожный — еще и запишет это в договор.
  В проекте Домино нам повезло, причем дважды. Изначально проектом занималась Ольга Семирогова (Воробьева), которой принадлежит колоссальная роль в проектировании сайта. К сожалению, в разгар проекта она покинула компанию, и запускали проект мы с Алексеем Маркеловым, который проявил и знания, и опыт, и здравый смысл. Все получилось, хотя смена контактера в проекте это один из самых тяжелых рисков.

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

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

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

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

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

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

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

• распознать большой проект
  Вовремя понять что проект новый, крупный, рискованный и увидеть свои риски, а затем понять как ими управлять.
• оценить проект
  любым способом, которым он владеет, постараться оценить объем трудозатрат, а потом разумно применить «множители»: новая технология, слабое ТЗ, сжатые сроки, отсутствие слаженной команды, плохо проработанные ограничения.
  Вообще говоря, есть статистически проверенные методики оценки масштаба проекта PERT, CoCoMo II и другие. В чистом виде они вряд ли сработают, но полезные мысли в них есть.
• определиться с методикой управления проектом
  среди разработчиков часто популярны современные, так называемые «гибкие» технологии управления проектом. У них есть множество достоинств, но есть и связанные с ними сложности. Очень важно понять как вы будете работать и договориться об этом с клиентом.
• составить список рисков
  И решить что делать с каждым: принять, передать, застраховаться, снизить. Главное — увидеть.
• сделать все для успеха
  нормальный амбициозный разработчик захочет добиться результата. Вопрос — сможет ли.

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

Есть общие риски большого проекта, которые есть всегда. Есть и специфические для веб-технологий. Вот самые значительные:

• неправильная оценка задачи исполнителем и слишком большое доверие со стороны клиента.
  Плохо даже не то, что исполнитель ошибается в оценке задачи и своих сил. Плохо то, что он не понимает что его оценки очень слабо обоснованы.
• риски, связанные с техническим заданием и другими описаниями проекта
  Есть две главных проблемы:
  — клиент может не понимать языка технического задания и даже отказываться вообще работать по нему. Мол, я вам уже все сказал, вы меня услышали, теперь делайте.
  — на большой проект получается техническое задание в десятки и сотни листов, со множеством схем и таблиц. Даже при исключительно грамотных, организованных и мотивированных сотрудниках с обеих сторон такой документ будет содержать ошибки, неточности и противоречия. Он будет неполон и местами неактуален, особенно к концу проекта. У руководства обязательно сменятся приоритеты и появятся новые идеи.
  Практика показывает что даже через несколько месяцев чтения ТЗ в нем можно найти пару удивительных абзацев, существенно меняющих уже сформировавшееся понимание.
  Чисто теоретически можно написать исчерпывающее непротиворечивое и подробное ТЗ на проект, но на это будет потрачено огромное время, за которое текст ТЗ устареет сам проект будет не столь актуален.

• большие сроки и утрата контакта
  Если разработка ведется большими этапами, к чему логично приводит попытка сделать «все сразу по большому ТЗ», в процессе работы утрачивается человеческий контакт между сторонами, многие детали забываются, заказчик устает ждать и испытывает скорее негатив чем предвкушает успех. Этот риск лежит не столько в рациональной сфере, сколько в эмоциональной, и оттого он опаснее.
  Его последствия — трудности при приемке, неконтролируемый поток пожеланий, которые заказчик считает ошибками или логичными требованиями, а исполнитель — чистыми «хотелками».
  Этот риск в итоге угрожает не только проекту, но и отношениям между сторонами.
  Этот риск частично реализовался в нашем проекте Домино. Мы делали его больше года, и за это время многое поменялось. На наш взгляд, лучше было запустить сначала один самый сложный раздел (например Авто), обкатать на нем общий механизм и потом развиваться. Заказчик же предпочел узнать цену и срок на «все сразу», хотя многое не было готово к такому крупному этапу. В результате было потеряно много времени, нервов и денег.
  
• изменение требований и цена развития
  Изменения в проекте это совершенно нормально для клиента, для бизнеса, для жизни. Ничего железобетонно устоявшегося в реальной жизни нет. Независимо от того, какую методику управления проектом вы выбрали — изменения будут.
  Возможно, договором или практикой отношений их удастся минимизировать или даже задавить вовсе, но это противоестественно. И каждый следующий день проекта до запуска будет только копить эти изменения
  Для разработчика же работа в условиях изменяющегося задания подобна гонке Ахиллеса за черепахой: близко, а догнать не удается.
  Есть несколько способов работы с таким риском, выбор между ними зависит от проекта и от отношений клиента с разработчиком.
  Общая же рекомендация — этапы меньше, запуск быстрее.
  При плохой работе с этим риском могут быть сразу 2 последствия:
  — проект всегда готов на 90%,
  — цена развития (во времени, деньгах, нервах становится неприемлемо высокой: качество страдает, принимаются сиюминутные решения, тестирование отсутствует).

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

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

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

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

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

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

В теории все просто.

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

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

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

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

• Заказчик редко готов дать ту информацию, которая объективна нужна для проекта. Меняется не только техническая сторона требований, но и понимание бизнес-результата. Часто в ходе проекта в самый непредсказуемый и неудобный момент меняются ключевые сотрудники заказчика.
• Исполнитель (под давлением заказчика или от собственной неопытности) редко имеет запас по срокам и деньгам на реализацию рисков. Если в малых проектах такая стратегия еще жизнеспособна, то в больших, когда рисков много и часть из них точно реализуется, это крайне опасно.
• Названные без запаса сроки и стоимости потом сложно поменять, и уложиться в них не получится если хоть что-то пойдет не так.
• Почти исключено чтобы разработчик держал наготове программистов чтобы включить их в проект. Скорее всего, люди будут браться с других работ, часто с наложением задач. Это все крайне усложняет планирование ресурсов и повышает требования к соблюдению сроков.
• А сроки в крупных проектах почти всегда срываются.

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

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

Я уже упоминал ситуацию, когда один и тот же проект вполне вменяемые разработчики по техническому заданию оценивали в разное время и стоимость, и разброс оценок был почти в 100 раз. На первый взгляд причина проста — разработчики жадные идиоты недостаточно опытные и ошибаются. На самом деле все сложнее. Даже при наличии опыта и знаний точность оценки проекта по ТЗ, особенно краткому, крайне низкая. Если же бумажного внятного документа с описанными ограничениями нет, стоимость смело можно брать «с потолка»: все равно ошибетесь. Это объективная реальность, что вначале проекта никто не знает его стоимости и сроков запуска. Существующие научно и статистически обоснованные методики крайне слабы и на практике малоприменимы. Что же можно сделать чтобы проект получился (интерес заказчика) и принес прибыль (интерес разработчика), а сроки уложились в отведенные рамки (всем хочется):

• грубая оценка с запасом и детальный план
  Действительно, можно сделать грубую оценку, сделать на нее запас в 10 раз на все риски сразу (запас кажется огромным, однако если риски не анализировались, никто не знает достаточен ли он), а затем составить детальный план и по возможности не давать заказчику никакой свободы в пересмотре требований и сроков.
• сначала ТЗ, потом оценка
  Можно заключить отдельный договор на написание детального ТЗ. Это стоит 10-30% цены самой разработки. Проблема в том, что клиенту обычно не нравится что он оплачивает ТЗ, которое, на его взгляд, нужно только разработчику. Кроме того, большое и подробное ТЗ это само по себе отдельный риск.
• разработка небольшими порциями
  Этот подход становится все более популярным. Разработка ведется небольшими порциями длительностью от 2 недель до 3 месяцев, задания на которые не очень большие. Оплачивается каждая порция, каждая порция запускается и расширяет возможности проекта. Технология хороша тем, что у клиента всегда есть продукт, которым можно пользоваться. Нет многих рисков: потери контакта, большого ТЗ, отсутствия тестирования. Есть и минусы: никто не знает сколько порций потребуется, какая будет в итоге стоимость и срок разработки. Клиенту часто это не нравится.
  Впрочем, это симметрично: разработчик никогда не знает всей задачи, что часто ему не нравится.

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

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

Парадокс в том, что большинство разработчиков применяют стандартный договор ни о чем. Такой договор не фиксирует сроки, обязательства, разделение ответственности, форму представления материалов и прочее. По недавно опубликованному исследованию, 30% сайтов делаются вообще без договора. Если при создании сайтов-визиток это простительно, но проекты на тысячи человеко-часов делать по слабому договору просто нельзя. Итак, каким должен быть договор:

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

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

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

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

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

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

Какую схему мы применили в проекте Домино, и она хорошо сработала:

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

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

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

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

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

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

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

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

При сдаче проекта всегда делают пользовательское тестирование, иногда unit-тесты кода. Мы считаем что еще один вид тестирования экстремально важен: нагрузочное.
Расскажу на примере Домино:

• прямо в договоре мы записали требования к работе сайта на разделяемом хостинге: 200 тысяч просмотров в сутки (примерно 3 просмотра в секунду), среднее время генерации страниц до 0.5 с, доля ошибок 50? не более 1%
• специфика проекта в том, что данные очень интенсивно обновляются и механизмы кеширования работают не очень эффективно
• при сдаче проекта мы провели тест (хостинг Timeweb, тариф Eterno). Среднее время генерации было около 0.2 секунд, ошибок 500 не было вообще. 200000 просмотров сайт выдержал легко
• показательно что в ходе теста было найдено около 10 узких мест в коде, потребовавших переработки. Устранение этих проблем дало примерно двукратное сокращение.
• когда решили переехать на отдельный сервер с хостинга, эти же механизмы проведения нагрузочного тестирования помогли быстро выбрать лучший вариант.

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

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

Выводы

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

• работа этапами — лучший вариант;
• обмен данными с внешними системами нужно делать и тестировать в самом начале проекта;
• работать над заданием нужно коллективно и «в прямом эфире» через Google Docs;
• большой проект это всегда политика, и он всегда существенно меняет бизнес;
• и помните: ваш следующий проект не должен превышать предыдущий более чем в 2 раза.

И еще вывод

Заказчик должен понимать что в проекте ему предстоит делать очень многое. Нужно будет выделить сотрудника, который будет иметь знания, компетентность и право принимать решения по проекту. Этот сотрудник должен будет выделять на проект много времени, возможно весь рабочий день.
И все получится.
Новый сайт Домино
Первоисточник статьи, оформленный немного аккуратнее. Извините, воевать с парсером хабра тяжко.

Автор: stepan_ovchinnikov

Источник