Статья написана по опыту запуска больших (400+ часов) и очень больших (1200-4000 часов) проектов.

Начнем с вывода.

1) При создании большого веб-проекта нужно выбрать самое важное и запустить его как можно быстрее, не тратя деньги и время на «доведение до идеала».

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

3) Медлительные перфекционисты проигрывают.

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

— А мой проект — большой?

Большие проекты это, например

• крупный интернет-магазин с развитой логикой и нестандартным обменом с учетной системой (примеры: Mybox, Shell, 7 соток, Siemens);

• портал-поисковик-каталог по туризму или недвижимости, онлайн-база данных (База данных федерации подводного плавания РФ);

• крупный многоязычный корпоративный или информационный портал (Дискуссионный клуб Валдай);

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

• «биржа» для объединения на одной платформе поставщиков и покупателей (почти «avito», другой «ebay», специфический аукцион, пример — Клуб клиентов Альфабанка);

• сайт, который обменивается информацией более чем с 1 внешней системой (почитайте про внешние интеграции на Битрикс и Битрикс24).

Тезис: веб-проект, требующий более 3 человеко-месяцев производства — большой.

Такой проект стоит у хорошей студии больше 600 тысяч рублей.

В 3 человеко-месяца вполне укладываются красивый корпоративный сайт, несложный интернет-магазин или посадочная страница.

Небольшие сайты можно делать «за один присест».

— Почему перфекционисты проигрывают?

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

Тезис: любой проект надо запускать как можно раньше, проверяя идею и реакцию на нее, даже если реализация далека от совершенства.

— Я бы взял частями, но мне нужно сразу!

Мысль «запускать как можно раньше, даже если проект далек от совершенства» — сначала шокирует. Как так? Запускать несовершенное? Недоделанное?

Хотите угадаю, что вы думаете?

— «Мы напугаем людей», «Так нельзя, мы делаем лучший продукт в мире», «Без всех функций результат нам не нужен», «Мы точно знаем, что нужно нашим клиентам, и на меньшее не согласны!»

Итак, вы хотите крупный проект.

Знакомые веб-программисты, которые делали лендинг в прошлом году и сайт-визитку в позапрошлом, призадумались. Потом сказали: «большой проект, мы наверное не возьмемся».

Незнакомые программисты, которых вы нашли в Яндексе, подозрительно быстро согласились. Вопросов не задавали. Сказали «А что, сделаем. Давайте ТЗ».

Тогда призадумались вы. Техническое задание (ТЗ) на большую работу вы никогда не писали. А если ваши сотрудники сделают это, не факт что все поймут его одинаково. Кроме того, это требует денег и времени. Сколько? Много!

Тезис: исчерпывающее ТЗ на проект, требующий более 3 человеко-месяцев, занимает не менее 50 страниц текста с картинками. Иногда 150. И писать его должен профессионал.

— Почему опасно писать «подробное ТЗ» из 50-100 страниц на большой проект?

Почему же? В чем проблема? Ведь каждому инженеру ясно: большое дело начинается с проекта.

Вот почему:

1. Долго писать и трудно читать.

   Написать ТЗ на 400+ часов кода быстро не выходит. По опыту такая работа занимает не менее 1.5 месяцев, а если нужно протестировать, спроектировать и доработать обмен с учетной системой — то и больше;

   Полученное ТЗ огромно (есть примеры документов на 200+ страниц), и ни один человек, даже менеджер проекта, не помнит всех нюансов. Заказчик такое ТЗ не дочитывает, не вполне понимает. Порой проще махнуть рукой и подписать «ребята вроде внимательно слушали, подпишу так»). Неопределенность растет. Хотя цель была — сделать проект однозначным;

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

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

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

   Интеграции надо не описывать в ТЗ, а сразу реализовывать и проверять. Без дизайна и обвеса.

3. Чтобы получить точную оценку, понадобится неделя хорошего специалиста. И эта оценка будет завышена.

   Даже если техническое задание есть, его оценка при объемах 400+ часов становится крайне неточной.

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

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

4. Более 6 месяцев производства, более месяца на тест и приемку.

   А если заказчик не получает результата за 3-4 месяца, ему становится скучно, бизнес меняется, рубль падает и вообще;

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

   И самое главное — много месяцев вы финансируете то, чего НЕ видите.

5. Возникает желание «выложить часть». А это на полпути сделать нельзя.

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

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

6. Низкий КПД.

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

Тезис: нужно собрать требования к функциям, внешним связям, погрузиться и разобраться.

Но не нужно пытаться написать ТЗ-догму, определяющее все детали, объемом 50-100 страниц.

Такое ТЗ НЕ РЕШАЕТ задачи создания проекта одним большим куском.

А как надо? Надо — итерациями. Поэтапно. Частями.

Это удобно (всегда есть работающая версия), это быстро (не год, а 3-4 месяца на старт), это безопасно (можно уточнить планы).

— Возьмите больше программистов и сделайте все параллельно!

Есть расхожая шутка про то, что 9 женщин за месяц ребенка не родят. Это верно, но попробуем объяснить почему.

Возьмем типичный проект.

Что тут можно сделать в 4-6-8 рук, распараллелить?

• Написание ТЗ? Нет, тут нужна одна светлая голова и обсуждение с Заказчиком.

• Настройка обмена с 1С? Это поэтапный процесс, а не покраска забора: с любого места не начать.

• Дизайн? Долго делается главная (одним человеком), а внутренние это относительно недолго.

  И да, дизайн внутренних страниц можно делать параллельно.

• Верстка? Примерно так же как дизайн, большими усилиями ускоряется процентов на 30.

• Программирование основных функций? Да, можно посадить двух программистов.

  Крайне редко — трех. Остальные начинают мешать друг другу.

Тезис: интернет-магазин (проект, дизайн, верстка, код, интеграция, тест) в 1000 часов вместо 8 месяцев теоретически можно сделать за 6. Меньше — нет.

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

— Вы хотите схалтурить и отдать мне недоделанное!

Наоборот.

Мы НЕ хотим халтуры, поэтому предлагаем итерационный подход.

Мы хотим быстрого старта проекта.

Тезис: итерационный запуск лучше чем «одним куском». Со всех разумных точек зрения. Придержите ваш миллион.

— Что можно сделать за 2-3 месяца и 400 часов?

Возьмем большой интернет-магазин.

Первая итерация: мини-тз, дизайн главной, каталог, передача данных из 1С, оформление заказов.

Сразу можно посмотреть, пощупать, обсудить.

А приоритеты на следующий шаг можно поменять, это нормально.

Дальше будут добавлены:

• каталог с умным фильтром и рекомендуемыми товарами;

• адаптивный дизайн и мобильное приложение;

• частичные оплаты, отгрузки, группировку заказов, развитый личный кабинет;

• импорт скидок из 1С;

• внешняя система аналитики;

• все что угодно.

— Если я покажу клиентам сырой продукт, они испугаются и уйдут!

Если вы покажете ценную идею, они не уйдут, они вас поддержат и выскажут пожелания.

Можно сделать «закрытый показ для своих».

«Основа проекта» проще в освоении и понятнее клиентам. Вы сделаете на второй итерации то, что им и вам нужно. А появление новых возможностей и развитие системы — отличный «информационный повод».

А вот если вы сделаете слишком сложный продукт — они уйдут точно.

Тезис: не страшно показать сырое. Страшно потратить миллион на мертвый проект.

— Я покажу конкурентам идею, и они меня опередят!

Конкуренты должны успеть сделать проект. Как мы с вами только что поняли — это долго.

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

Тезис: Итерациями — быстрее. Выиграет тот, кто первым встал и быстро бегает.

— Наш директор хочет знать бюджет! Без точной суммы мы не начнем!

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

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

Или вы заплатите в 2.5 раза больше, поверив оценкам «со страху»,

Или программисты занизят стоимость и потом будут доделывать все в убыток себе или «тяп-ляп».

«За что не доплатишь, того не доносишь».

Тезис: Это понятное, но трудно осуществимое, даже вредное желание — узнать и зафиксировать стоимость работы «после первых переговоров».

Что конкретно вы предлагаете? Как это: делать проект итерациями?

Готовы? Заполните заявку.

— Ну... хорошо. Не убедили, но было интересно

Это не все. Мы подготовили кое-что еще более интересное.

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

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

Но мы считаем эти проекты (в которых мы старались, никто не болел, участвовали лучшие люди) провальными.

Потому что вместо 4 месяцев ПЕРВЫЙ полезный результат люди получали более чем через год (!!!) с момента старта работ.

Мы готовы рассказать подробности об этих провалах и о том, как НАДО было делать.

Расскажем не всем, и не публично.

«Поделитесь» статьей в соцсетях, мы пришлем вам продолжение. Форма под статьей, поспорьте с нами.

— Я согласен на поэтапный запуск. А вы так уже делали? Примеры есть?

Конечно.

По такой технологии мы работаем над сайтами Издательства Учитель http://www.uchmag.ru/, http://www.uchmet.ru/, клубом клиентов Альфа-Банка https://club.alfabank.ru/, интернет-магазином http://mybox.ru/ и еще десятком проектов.

Заполните заявку.