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

Шрифт
Интервал


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

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

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

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

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

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

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