Как строить большие и сложные проекты
Борщ классический
В роли "кочана капусты" возьмём проект разделяемый на составные части (или этапы), а потом собираемый по кускам из результатов этих этапов. Рисуем макеты, верстаем шаблоны и оживляем технологиями. Лист за листом оборачиваем кочерыжку технического задания. Ближе к концу проекта кочерыжку уже не видно. Сотрудники стремятся разойтись по углам: каждый выполняет свою работу, взаимодействовать стимула нет, а в углах работать комфортнее — никто не мешает.
Что делать с людьми
Наблюдайте как изменится ситуация если объявить дизайнерам и разработчикам, что теперь результатом работы считается продукт.
Дизайнеру теперь невыгодно выдавать нежизнеспособные макеты: если разработчики не смогут их реализовать, значит продукт не готов. Разработчику же придётся расспросить дизайнера обо всех нюансах поведения интерфейса: если продукт работает не так как ожидал заказчик, то разработчик не сделал.
Все предположения неверны
Тех. задание это ограничитель для фантазий заказчика. Чтобы потом не менять ничего или менять, но за деньги. На практике в таком виде оно не нужно никому. У тех. задания другая роль — убедиться в том, что менеджер/дизайнер/разработчик понял задачу.
Изменения — это нормально. Они возникнут на этапах проведённой работы: после столкновения ожиданий заказчика с прототипом или готовым результатом или после изменений в бизнес-процессах заказчика. Зная об этом важно учитывать этот фактор при организации своих процессов.
Метод Брокколи
— "Брокколи состоит из маленьких брокколи, а маленькие из еще более маленьких — очень красивый принцип, который позволяет из простых элементов создавать сложность".
Смысл подхода в том, что каждая итерация приносит не кусок пазла-продукта, а готовое решение содержащее полезные функции. Чтобы проверить достаточно ответить на вопрос может ли заказчик уже в таком виде использовать это решение?
Первое правило проектирования сложных приложений — не строить сложных приложений.
Чем меньше задача и конкретнее польза от её решения, тем лучше. С таким подходом проще создать видение конечного результата как у заказчика, так и у команды. На коротких дистанциях проще управлять ресурсами.
Сложности
Через такой метод сложно пронести булшит, а это значит, что с части клиентам придётся отказать. Те кто останутся не сразу поймут пользу метода.
Для примера можно вспомнить о негативном опыте. Как однажды взявшись за сложный и большой проект стараясь соблюсти качество (про сроки тактично умолчим), его стоимость оказалась посередине большого болота. До нее трудно добраться, но еще труднее, получив её, из этого болота выбраться: выполнить свои обязательства перед заказчиком и закрыть сделку.
P.S. Дополнительно начинающим ПМам советую посмотреть сборник ссылок от Никиты Михеенкова из Nimax.
