Заметка написана для тех руководителей, кто имел негативный опыт заказной разработки сайтов для своей компании. Не поленитесь, дочитайте до конца. Может быть, это сэкономит вам несколько сотен тысяч рублей.
Возможно, прямо сейчас ваш сайт нужно переделать. Поводов для переделки может быть много: от банального устаревания дизайна до желания интегрировать сайт с внутренней инфраструктурой компании. Или добавить ему мобильности.
Нужно звать веб-разработчиков. И если у вас был опыт общения с этими милыми, добрыми людьми, и вам периодически хотелось подкрутить у них чего-нибудь в голове (отверткой), чтоб лучше работали — тому есть причины!
1. Цена вопроса
Допустим, вы решили переделать ваш устаревший сайт. Какой вопрос будет интересовать вас в первую очередь? В большинстве случаев — цена. Действительно, «сколько стоит сайт» — обычно первый вопрос, с которого начинается общение (это происходит практически в 100% случаях, а мы в СПАЙК принимаем по 4–8 таких звонков в день).
Почему?
Во-первых, цену можно сравнить. И самое главное — тут не надо разбираться, разжёвывать каждому разработчику все требования и нюансы, понимать, чем они отличаются (и отличаются ли) друг от друга. В отличие от мутных требований, которые, скорее всего, вы еще не можете четко сформулировать для себя сами (не знаю, чего хочу), цена — это конкретное число.
Во-вторых, цену можно отжать. После этого какое-то время чувствуешь себя героем. Ну и в принципе, раз ребята прогибаются — с ними приятно иметь дело ;)
В-третьих, названная цена снимает с вас ответственность за формулирование требований и переносит их на разработчика. Они обещают вам сделать проект за конкретные деньги.
2. Существенные критерии
Какие еще существенные критерии, кроме цены, у вас есть? Тут называют много: сроки, качество, компетенции… Вернее то, как, разработчики РАССКАЗАЛИ о своих сроках, качестве и компетенциях. Это называется «Зажигательность обещаний» :)
3. «Просто пришлите КП!»
Очень часто первоначальный сбор коммерческих предложений поручают тому, кого не жалко. (Замечу, что не всегда: в ответственных компаниях, которые понимают важность проекта, сразу выделяют толкового и ответственного человека и дают ему достаточно ресурсов и полномочий).
Тем не менее, ситуация, когда «собрать цены» поручают зеленому сотруднику две недели от роду, очень распространена. Такой сотрудник, как правило, не знает ни планового бюджета проекта, ни целей, ни технических деталей. Он не обладает достаточным опытом, авторитетом и компетенциями. Его мнение вряд ли будет учтено начальством при выборе подрядчика. Его личные перспективы на проекте — отдал КП и свалил в сторону.
Как вы думаете, будет ли такой человек париться из-за вашего проекта? Будет ли он досконально прорабатывать и продумывать с потенциальными подрядчиками оптимальную структуру и вдаваться в технические тонкости?
Скорее всего — нет. Скорее всего, как только студии начнут задавать ему много вопросов (а они начнут, если хотят подготовить почтенным людям почтенное коммерческое предложение), он переключит фокус на тех, которые таких вопросов не задает. И просто пришлет КП.
4. Выбор подрядчика
Итак, вот какие критерии выбора у нас набрались:
- Цена: они должны хотеть мало денег;
- Прогибаемость: они должны прогибаться;
- Зажигательность обещаний: красиво поют (просто хор Турецкого!);
- Не задают неудобных вопросов.
ПРИВЕТ ПОСЛУШНЫМ ИДИОТАМ!
Коллеги, у меня вопрос: с чего вы взяли, что эти люди сделают вам проект? Если ответ «Ну, они же обещали» — читаем дальше :)
5. Контракт — гарантия ВСЕГО!
На самом деле — нет. Основных причин тому три:
5.1. Поехали, потом заведешься
Начинали ли вы ваш прошлый проект, не до конца понимая, что именно вы хотите получить на выходе? Скорее всего — да. Я сам так делаю. В общем-то, это нормально (именно поэтому так хорошо работает scrum), когда требования конкретизируются по ходу. Кому интересно, как это работает, — сходите потом по ссылке, почитайте!
Однако цену-то мы хотим зафиксировать сразу. А требования — нет. Добавлять по ходу.
Более того, в нашей культуре вполне себе нормой является отношение к подрядчикам «Мне плевать на их прибыль» и «Хочу результат за их счёт». По опыту работы с западными компаниями могу сказать, что в США и Европе это не так.
Вопрос. Каким обманом вам ответит команда разработки, если поймет, что не сможет на вас заработать из-за постоянно растущих требований?
Правильно. Плохим внутренним качеством. Качеством кода. Костылями.
Особенно больно это аукнется на крупных проектах, когда вы попробуете их развивать и поддерживать. Все будет тормозить, глючить и ломаться. И никто не захочет брать такой проект на техническую поддержку за вменяемые деньги.
5.2 Но мы же договорились!?
Обычно со стороны и подрядчика, и заказчика контракт согласовывают первые лица компании. В общих чертах им все понятно.
— Петрович — сделаешь?
— Да!
Дальше Петрович приходит к программистам, и там происходит примерно такой диалог:
— Программисты, делайте!
Программисты честно спрашивают:
— Чо?
— Ну вот ТЗ. Будет. В следующем месяце…
Нормально. И потом, когда сайт готов:
— Логисты, вот вам новый сайт! Следите теперь за заказами в админке. Вот доступы!
— !@#%!!!
Проблема в том, что договаривались одни люди, делать будут другие, а пользоваться — третьи. Буквально с первых секунд происходит разрыв ожиданий.
5.3. Но мы же можем зафиксировать все требования!
Ага, щас. Вот вам два примера:
Машинки назывались «Инвалидка», или, по научному С-3Д («эс-три-дэ»). Устройство рядом — детище компании… Microsoft! Да, это «убийца» iPod — плеер Zune. По коричневому цвету видно, что продукт — полное говно рассчитан на молодежь.
Что не так с обоими продуктами? У машины есть колеса, она ездит; плеер — играет, есть экран, листалка песен — колёсиком. Скорее всего, изделия ПОЛНОСТЬЮ соответствуют поставленным заданиям. Вроде как и функции все на месте, только пользоваться результатом не очень хочется.
Этот ужас и кошмар обусловлен тем, что в техническом задании зачастую невозможно (или сложно) прописать нефункциональные требования. Даже если задаться целью получить максимально подробное описание проекта в ТЗ, это не удастся. Всегда будет повод двойной трактовки требований. И чем детальнее вы будете их расписывать, тем сложнее будет с ними работать. Но от двойных толкований вас это не избавит.
Скорее всего, на проекте появятся какие-то переделки. И если вы прогнули разработчика в цене — готовьтесь, тут-то он вам и отомстит. Особенно если разработчик понял, что долгосрочные отношения с вами у него не получатся. Вы будете тратить многочисленные часы на препирательства, было ли это в ТЗ или нет («Ну, если не на самом контракте, то хоть на переделках-то я и заработаю»).
Итак, реалии таковы, что контракт, который вы подписали и «договорились» — не гарантирует вам легкой жизни и успешного проекта. Увы.
6. Мы УЖЕ опаздываем!
Серьёзно. Как обычно стартуют проекты: приходит Большой Босс с паяльником, и говорит «Нам срочно нужен проект Х. И Мы УЖЕ опаздываем!». А паяльник такой большой, красный. И тут все начинают бегать-суетиться. Общая идея — если не сказать людям, что они уже опаздывают, если не загнать их в нереальные временные рамки — они расслабят булки и будут делать проект годами.
Чем ответит разработчик на требования нереальных сроков?
«Честный» ответит: «Не-е-е, это невозможно». И не получит контракт. А если вдруг получит, будет периодически раздражать заказчика нытьем «мы не успеваем», «мы опаздываем». Чем, собственно, будет очень нервировать заказчика, получит общественное презрение, порицание и дурную репутацию.
«Опытный» ответит: «Сделаю». Заберет контракт. Потом по ходу работы будут бодрые рапорты: «Все по графику!», «Все по плану», а в последний день: «Извините, прилетели марсиане, увезли на Марс главного программиста, все сервера и исходный код. Нужно еще пару месяцев на доводку вашего проекта».
Замечу, что «Опытный» получит по башке всего один раз, а «Честный» будет получать каждый день. Большой, красный паяльник у босса, желание показать конкурентоспособные сроки и возможность «потерпеть боль всего один раз» провоцируют разработчиков сразу говорить нереальные сроки. Ничего удивительного, что их часто срывают.
7. Черные дыры
В чем разница между адронным коллайдером и типовой компанией web-разработчиком? В том, что в коллайдере черную дыру только пытаются получить, а в компаниях разработки она реально есть!
Как и чего там происходит — со стороны понять вообще невозможно. Бессистемность и непрозрачность рабочих процессов web-разработчиков — хорошо известный, но плохо излечимый феномен. Даже если процессы разработки хорошие, часто это непрозрачно для клиента. И это, конечно, способствует «хорошим» отношениям с заказчиком: появляется виноватый. В любой ситуации можно сказать: «Они там что-то намутили, поэтому все тормозит, глючит и работает не так».
Что делать
Собственно, я это все написал не для того, чтобы поковыряться в больной ранке у web-разработчиков и заказчиков.
Во-первых, нужно понять, что современные web-проекты — это зачастую довольно сложно устроенные вещи. Мы уже давно не в песочнице. И заказать интернет-проект — это не тоже самое, что заказать двадцать кубов бетона (хотя, говорят, и там есть нюансы). Вариант «я им денег — они мне счастья» — не работает в принципе. Вариант «я им денег и ТЗ, они мне — счастья» — не работает тоже.
На технически сложных web-проектах, которые глубоко завязаны на ваши бизнес-процессы (или могут их даже в корне изменить), необходимы:
- Деньги (да, конечно).
- Актуальные требования и ожидания (вместо один раз за коленке написанного ТЗ). Тут, кстати, хорошо поможет scrum с возможностью менять требования на ходу и интерактивные прототипы вместо толстых ТЗ, которые никто не читает.
- Поддержку в поле власти. Проект должен получить добро на самом высшем уровне, а не быть инициативой мальчика-из-маркетинга вторую неделю на испытательном сроке. Чтобы разработчик имел потенциальную возможность получать нужную ему информацию от заинтересованных в проекте лиц в вашей компании.
- Перспективу долгосрочных отношений (чтобы знал, что это проект ему поддерживать и развивать еще до-о-о-лго).
- Время. Адекватное время на разработку системы. И адекватное время, которое руководитель проекта со стороны заказчика будет выделять на решение ключевых вопросов по проекту.
- Достоверную и непротиворечивую информацию. До старта проекта важно учесть требования всех потенциально заинтересованных сторон: логистов, бухгалтерии, сэйлов, маркетинга и т.д.
- Короче, всех, кого может коснуться сия напасть.
Что нужно требовать:
Открытости. Разработчики должны объяснить, КАК именно они собираются добиться результатов. Не просто обещания, а четкий и понятный план, как именно требуемый результат появится в нужные сроки. Какие техники будут применяться на прототипировании, дизайне, планировании итераций, или планировании сроков всего проекта, разработке, ежедневном контроле, тестировании, отчетности или технической поддержке.
И только в такой конфигурации на вашем проекте может наступить простое человеческое счастье :)
Всем добра.
4 июля 2014 г.
Что еще почитать по теме:
- Протипирование интерфейсов в Axure.
- Как доски настроения помогают попасть в ожидания заказчика на этапе дизайна.
- Планирование по agile-методологиям с помощью Planning Poker.
- Как работать с клиентом по agile удаленно.
- Доска для входящих заявок — как не терять лидов и визуально контролировать весь процесс пресейла.
- Инфографика: цикл тестирования в Сибириксе.
- Еженедельные отчеты клиентам: простой способ управлять ожиданиями.
- Десять заповедей технической поддержки.
Благодарности:
Сергею Бережному за умные мысли :)
Автор: zevvssibirix
