cover

Мы с коллегами из Itransition подготовили серию статей о том, что происходит перед началом любого IT-прокета и как себя вести, если вы — клиент. Эти советы подойдут при работе с любым IT-вендором:

  1. Предпродажа
  2. Анализ
  3. Старт проекта

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

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

Вот, что нужно сделать, чтобы эти деньги не улетели в выхлопную трубу.

Определите, где вы можете сэкономить

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

Одни и те же функции можно реализовать разными способами. Например, регистрацию можно сделать по email, а можно — с подтверждением по SMS. Хороший вендор умеет и так, и эдак — только стоимость будет разной. Если вам всё равно, какая регистрация, то делайте по email или вообще подключите готовый модуль — так дешевле. Если нужна по SMS, то придётся сделать дороже — смело говорите об этом на фазе анализа и вносите в план.

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

Выберите модель сотрудничества

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

Если нет жестких ограничений по бюджету, будут меняться бизнес-требования и нет окончательного видения системы, то весь проект лучше делать небольшими частями. Обычно их называют «спринтами». Размер спринта выбирают так, чтобы успеть сделать какой-то кусок системы до конца. Потом приступают к следующей части и снова доделывают её за спринт. Фактически, на таком проекте у вас будет одна общая фаза анализа в самом начале и ещё куча по ходу проекта — перед каждым спринтом.

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

Менять требования под нужды бизнеса на лету — это круто, но управлять бюджетом в таких условиях очень трудно. Скорее всего, за всеми этими переделками вы и не заметите, как бюджет изменился: может на 10%, а может и на 30%. Для таких условий подойдёт модель сотрудничества Time&Material — вы заплатите столько, сколько на самом деле понадобится.

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

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

В итоге у вас будет полная спецификация системы, техническое решение и план проекта. Теперь вендор знает, как это будет реализовано, примерно какой будет дизайн, как будет работать интеграция с другими системами и сможет назвать точную цену проекта. С ней вы сможете пойти к инвесторам или на защиту бюджета и сказать: «ребята, мне надо 131 638 $ и эти деньги будут потрачены так-то и так-то, результат будет тогда-то и тогда-то». Такая модель сотрудничества называется Fixed Price — стоимость проекта не изменится, но и переделать какие-то мелочи на ходу без изменения бюджета будет трудно.

Подумайте, что ещё вам пригодится

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

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

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

Prototype

Данные и дизайн ещё могут поменяться, но логика работы останется

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

А вот уже дизайн, который мы делали на фазе анализа. Покликать тут нельзя, зато ещё на фазе анализа ясно, как будет выглядеть система: мы смогли точно спланировать загрузку верстальщиков, а клиент — контент-менеджеров. Несколько экранов для примера:

mobile design examplemobile design example 2

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

Однажды к нам пришёл клиент, который хотел автоматизировать проверку паспортов: фотографируешь на смартфон страницу в паспорте, а система распознаёт и заполняет нужные поля сама. Раньше такого никто не делал и нам казалось, что тут будут какие-то ограничения. Сделали технический прототип — и точно, система работала плохо при том уровне технологий. Ламинированная страницы бликовали, поля распознавались плохо, клеркам было неудобно работать. В итоге клиент решил проект дальше не развивать.

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

Выделите время

На фазе анализа вам придётся ответить на очень много вопросов о вашем бизнесе и внутренних системах. Точно сказать, сколько это займёт времени трудно — всё зависит от размера проекта и степени неопределенности требований. Ориентируйтесь на трудозатраты в один-два человеко-часа в день с вашей стороны.

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

Чтобы этот процесс проходил безболезненно, заранее выделите время в календаре — своем и ответственных специалистов с вашей стороны. Для принятия решений на этой фазе как минимум нужны:

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

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

Что дальше

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