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

Но кто и как создает подобную документацию? Заказчик никогда не будет дотошно проверять многостраничные выкладки или детально объяснять, какой продукт ему нужен. Ограничится общей формулировкой идеи, параметров продукта, бюджета и сроков исполнения. Все детали отдадут на проработку случайному сотруднику, который распишет их на свой вкус и манер. Будет истрачено много времени на реализацию деталей, и первая версия продукта будет выпущена с опозданием. Естественно, после выпуска первой версии ждите огромного числа замечаний, разных доработок. Заказчик будет не в состоянии понять, почему продукт реализуется с недочетами.

На мой взгляд, лучше всего иметь краткую документацию с небольшим набором UML-диаграмм. Картинки в документации всегда легче обсуждать и менять. Больше визуализации, меньше текста! Нарисуйте дизайн и основную часть экранных форм, доработать их можно на любом этапе реализации проекта. Всегда держите своего дизайнера в боевой готовности. Он должен обладать навыками юзабилити-эксперта.

Прочтите несколько книг про UML и прототипирование пользовательского интерфейса. И не впадайте в крайность, требуя рисовать все диаграммы и экранные формы перед реализацией проекта.

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

Безусловно, планирование необходимо в любом серьезном начинании, но чересчур глубокая детализация бессмысленна. Любой план – это допущение вероятности, попытка предсказать будущие события. Много вы знаете предсказателей, которые ни разу не ошиблись? Вы сами не оракул и не ясновидящий. Разумнее всего создать общий план без детализации до уровня мелких подзадач. Это позволит вам менять ход работ по ситуации, какие-то мелкие подзадачи откладывать на потом, чтобы завершить проект или версию в срок. Руководствуйтесь правилом: план – ничто, планирование – все.

Надеюсь, мой позитивный опыт позволит вам избежать основных ошибок при запуске своего стартапа в сфере IT и достичь максимальных результатов!

Я работал на множестве стартапов, основывая их и выводя на высокий уровень. Каждый раз я ставил перед собой несколько основных целей:

Конец ознакомительного фрагмента.