Вам доводилось когда-либо взаимодействовать с разработчиками? А не возникало ли у вас после этого желание подкрутить отверткой чего-нибудь в их мозгах? Чтобы лучше работали. Потому что одно маленькое недопонимание — и ждите на проекте эдакой миниатюрной катастрофы.
От слов — к статистике: перед вами процент успешно завершенных интернет-проектов в США за далекий 1994 год:
А теперь 2012-ый. Думаете, многое изменилось?
На протяжении почти 20 лет между заказчиком и подрядчиком была какая-то преграда, мешающая вовремя сдавать интернет-проект, соответствующий требованиям. В чем проблема, по-вашему?
Дискоммуникация
Множество бизнесов теряло деньги из проекта в проект. С этим нужно было что-то делать. В результате была выработана концепция «гибкой» разработки в противовес стандартной.
Сегодня в разработке есть так называемая «водопадная» модель (стандартная) и «гибкая» модель (Scrum, читается как «Скрам»). Если коротко: первая не предполагает частого контакта с исполнителем, вторая — напротив, всячески его поощряет.
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
Сравните:
Стандартная модель: Waterfall / WTF
Суть «водопадной» модели заключается в следующем:
1. Вы анализируете потребности бизнеса, оформляете их в техническую спецификацию, отдаете в разработку. Техническое задание на проект средней сложности — это документ в 50 страниц, на разработку которого лично вы потратите достаточно много времени.
2. Начинается разработка, которая идет по определенным этапам: дизайн → верстка → программирование → тестирование → сдача проекта. Ждать, пока вы сможете «потрогать» проект, тоже придется долго.
3. Вы получаете готовый проект и работаете над его продвижением.
На первый взгляд, такая модель работы абсолютно комфортно укладывается в голове и выглядит самой очевидной. Однако у нее есть свои недостатки, и они существенные:
Во-первых, «водопаду» нужно, чтобы вы спланировали весь проект сразу. А это значит — спланировали бюджет, выдвинули пожелания к срокам выполнения и, самое главное, сделали техническое задание, где были бы учтены все требования. А зачастую, особенно, когда речь идет о каких-то инновационных проектах, продумать всё и сразу просто невозможно. Но «водопад» суров.
Во-вторых, «водопадная» модель не предусматривает вашего активного участия в работе над проектом. Вы передаете требования, получаете дизайн, снова отдаете требования — и прощаетесь с проектом до самого его релиза. Если мы говорим о небольших проектах-то «водопад» подходит идеально, но что, если есть объективная потребность контролировать весь процесс и корректировать его? К сожалению, снова мимо кассы.
В-третьих, в «водопаде» очень дорого обходятся изменения. Например, ситуация: ваш проект находится в разработке. Он сложный, поэтому разрабатывается уже давно. За это время рынок меняется, и какие-то функции на проекте становятся неактуальными. Вы звоните руководителю проектов и говорите, что такую-то функцию нужно переделать. Но полный функционал уже был описан в ТЗ, поэтому вам придется его переписывать и перезаключать договор, разработчикам — полностью приостанавливать рабочий процесс, а всё вместе это — потери времени.
В «водопадной» модели участие заказчика в разработке проекта минимальное (есть только на начальном этапе). По сути, вам не дают вносить изменения в проект и контролировать процесс, а потом демонстрируют готовый продукт. Логично, что такой «черный ящик» вас может не устроить:
Итак, если ваш интернет-проект небольшой, вы точно знаете требования и не собираетесь ничего менять — можете выбирать подрядчика, работающего по стандартной «водопадной» модели.
Scrum — гибкий, но твердый
Противовес стандартной модели разработки — «гибкая» модель (Scrum).
В Scrum весь процесс разработки строится иначе:
1. Вы также анализируете потребности бизнеса, но вместо технического задания просто готовите список всех функций (в этом вам помогает руководитель проекта).
2. Функциям присваивается приоритет (например, для интернет-магазина каталог товаров важнее, чем личный кабинет пользователя — следовательно, приоритет первого будет ощутимо выше).
Пример типичного списка компонентов интернет-магазина, с приоритетами:
1. Разработка идет отдельными этапами по принципу: выбрали на этап самые приоритетные функции (на рисунке отмечены красным) → подготовили дизайн → сверстали → запрограммировали → запустили проект с минимальным функционалом → снова выбрали приоритетные функции… И так до последнего этапа.
2. В результате каждого этапа вы получаете полностью готовый, работоспособный проект, в котором реализованы самые важные с точки зрения вашего бизнеса функции. Который уже можно запускать.
3. Пока идет, например, первый этап разработки, вы можете пересмотреть свое видение проекта и что-то поменять в последующих. И эти изменения не будут дорогостоящими, как в «водопаде».
4. Каждый последующий этап будет наращивать функционал проекта, пока все функции не будут реализованы.
Итак, если говорить об особенностях работы по Scrum’у, то нужно отметить:
- Прозрачность. В Scrum’е после каждого этапа разработки вам будут демонстрировать то, что получилось, а еще регулярно снабжать наглядными отчетами о том, как идут дела на проекте. Кстати, «хроника» работы над проектом, которая содержится в таких отчетах — очень полезная вещь при общении с боссом.
- Быстрые, дешевые изменения. Разработка ведется «кусочками», и это позволяет вам быстро внедрять новое в проект. Например, после окончания первого этапа и запуска проекта вы решили, что социальная сеть вам не нужна. Так как она имела меньший приоритет, к ней еще не приступали, а значит, вы просто связываетесь с руководителем проекта и вычеркиваете ее из общего списка функций.
- Быстрый запуск. Проект с базовыми функциями запускается уже после первых этапов разработки, после чего он с каждым этапом «обрастает» новыми функциями. А вы этим временем можете заняться, например, продвижением интернет-проекта в поисковой выдаче.
- Гибкий бюджет. В зависимости от того, как вы будете влиять на проект в ходе разработки — будет меняться и бюджет (причем, он может как уменьшиться, так и вырасти). В ряде случаев гибкость бюджета нежелательна, так как это мешает спланировать затраты (мы в таких случаях используем собственный метод — Scrum по фиксированной цене). А для стратапов и других продолжительных проектов, где сложно спланировать сразу весь бюджет, Scrum подходит безупречно.
Если у вас намечается длительный, сложный проект, которым вы живете и собираетесь жить ближайшие несколько месяцев — тогда только гибкая разработка и Scrum в помощь.
Еще одно очко в пользу Scrum — практика показывает, что успешно завершенных проектов, разработанных по Scrum, в 3 раза больше, чем таковых, разработанных по «водопадной» модели:
Источник картинки на тизере: IconArchive
Источник: