Статья посвящена реальному стартапу.
Статья написана Юрием Ветровым для информационного портала о стартапах Liveidea.ru
Работа со стартапами. Заказчик хочет быстро, инвестор — надежно.
Находимся на предпоследнем этапе работ по проработке интерфейса одного веб-стартапа. Компания-заказчик нашла отличного инвестора, так что есть возможность разрабатывать проект не силами друзей, а в рамках хорошо поставленного процесса. Правда, в прибавку к хорошему финансированию инвестор требует детальной отчетности. А часть этой задачи, как подрядчику, перепадает и нашей компании.
Вкратце о проекте. Работы разбиты на 4 этапа:
1. предварительный анализ и оценка проекта. Заказчик и подрядчик строят общую картинку будущей системы, оценивают работы по стоимости и времени и планируют их;
2. проектирование интерфейса и создание интерактивного прототипа. Начало работ над системой. Необходимо получить действующую ее модель. Во-первых, для того чтобы зафиксировать концепцию. Во-вторых, протестировать ее юзабилити с будущими пользователями;
3. спецификация системы и техническое задание на ее разработку. Нужно поставить четкое задание разработчикам. В этом поможет серия документов, описывающих базу данных, архитектуру системы, бизнес-логику, рабочее оборудование и прочие моменты;
4. разработка и запуск системы. Программирование и сопутствующие работы. По итогу — переданный заказчику.
Первые сложности начинаются с договора. Хотя у нас все этапы работ и расписаны достаточно подробно, требуется дотошность на уровне законотворческой. Несмотря на то что многие из сделанных нами документов нужны скорее для внутреннего пользования, всем им должно быть дано однозначное определение. Плюс ко всему их нужно инвентаризировать. До поименного перечисления файлов, конечно, не доходит, но список документов каждого типа должен прилагаться. Заказчику нужен максимально детальный отчет о проделанной работе еще до ее начала.
В процессе работ, например, концепция интерфейса может поменяться, поэтому приходится делать оговорки в подобных местах. Но после долгой серий правок все наконец довольны и договор на второй этап работ подписан.
Но есть и другие закавыки. Заказчик хочет видеть смету работ по всем этапам. Поскольку мы заключаем отдельный договор на каждый из них, он хочет оценить как общую стоимость, так и соотношение сумм по каждому из этапов. Размытость концепции (а соответственно, и объема работ) после первого этапа хоть и мешает точным цифрам, но разрешима. Примерные цифры выстроить можно и сейчас, хотя есть еще одна проблема.
В проекте будет использована внешняя система хранения цифрового контента — зарабатывать стартап планирует на нем. Следовательно, объем программирования с нашей стороны будет меньшим. Но на какую часть меньше? И сколько дополнительных ресурсов потребуется на интеграцию этих систем? Да и вообще, может быть разработку будет целесообразнее вести поставщику внешней системы? Выбирал ее заказчик и модель взаимодействия систем выяснилась не сразу. Но все-таки выяснилась, и вместе с ней — примерная смета и план работ по всем этапам.
Лишнюю головную боль от этого получили не только мы, но и сам заказчик. Из-за затянувшегося процесса принятия решений сдвинулись сроки проекта, хотя заказчик и планировал очень резвый запуск. Но тут уж им самим решать, что важнее — скорость запуска или подстраховка на все случаи.
Статья написана Юрием Ветровым для информационного портала о стартапах Liveidea.ru
Работа со стартапами. Заказчик хочет быстро, инвестор — надежно.
Находимся на предпоследнем этапе работ по проработке интерфейса одного веб-стартапа. Компания-заказчик нашла отличного инвестора, так что есть возможность разрабатывать проект не силами друзей, а в рамках хорошо поставленного процесса. Правда, в прибавку к хорошему финансированию инвестор требует детальной отчетности. А часть этой задачи, как подрядчику, перепадает и нашей компании.
Вкратце о проекте. Работы разбиты на 4 этапа:
1. предварительный анализ и оценка проекта. Заказчик и подрядчик строят общую картинку будущей системы, оценивают работы по стоимости и времени и планируют их;
2. проектирование интерфейса и создание интерактивного прототипа. Начало работ над системой. Необходимо получить действующую ее модель. Во-первых, для того чтобы зафиксировать концепцию. Во-вторых, протестировать ее юзабилити с будущими пользователями;
3. спецификация системы и техническое задание на ее разработку. Нужно поставить четкое задание разработчикам. В этом поможет серия документов, описывающих базу данных, архитектуру системы, бизнес-логику, рабочее оборудование и прочие моменты;
4. разработка и запуск системы. Программирование и сопутствующие работы. По итогу — переданный заказчику.
Первые сложности начинаются с договора. Хотя у нас все этапы работ и расписаны достаточно подробно, требуется дотошность на уровне законотворческой. Несмотря на то что многие из сделанных нами документов нужны скорее для внутреннего пользования, всем им должно быть дано однозначное определение. Плюс ко всему их нужно инвентаризировать. До поименного перечисления файлов, конечно, не доходит, но список документов каждого типа должен прилагаться. Заказчику нужен максимально детальный отчет о проделанной работе еще до ее начала.
В процессе работ, например, концепция интерфейса может поменяться, поэтому приходится делать оговорки в подобных местах. Но после долгой серий правок все наконец довольны и договор на второй этап работ подписан.
Но есть и другие закавыки. Заказчик хочет видеть смету работ по всем этапам. Поскольку мы заключаем отдельный договор на каждый из них, он хочет оценить как общую стоимость, так и соотношение сумм по каждому из этапов. Размытость концепции (а соответственно, и объема работ) после первого этапа хоть и мешает точным цифрам, но разрешима. Примерные цифры выстроить можно и сейчас, хотя есть еще одна проблема.
В проекте будет использована внешняя система хранения цифрового контента — зарабатывать стартап планирует на нем. Следовательно, объем программирования с нашей стороны будет меньшим. Но на какую часть меньше? И сколько дополнительных ресурсов потребуется на интеграцию этих систем? Да и вообще, может быть разработку будет целесообразнее вести поставщику внешней системы? Выбирал ее заказчик и модель взаимодействия систем выяснилась не сразу. Но все-таки выяснилась, и вместе с ней — примерная смета и план работ по всем этапам.
Лишнюю головную боль от этого получили не только мы, но и сам заказчик. Из-за затянувшегося процесса принятия решений сдвинулись сроки проекта, хотя заказчик и планировал очень резвый запуск. Но тут уж им самим решать, что важнее — скорость запуска или подстраховка на все случаи.
