От ботана-программиста до разгильдяя топ-менеджера. Практическое руководство для карьеристов

Заблуждение восьмое. Для создания продукта нужна полная документация, техзадание

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

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

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

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

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

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

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

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

ГЛАВА 4. СОЗДАЁМ СТАРТАП

Введение

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