#управление проектами

Сегодня общался с клиентом, который хочет знать, сколько стоит сделать маркетплейс.

Трагедия в том, что предыдущий подрядчик уже взял кучу денег и потратил полгода клиента «на разработку», не задав базовые вопросы о бизнесе. Честно говоря, у него и не было шанса запуститься вовремя.

Пускай это жёсткий пример, но история классическая:
1. заказчик описывает задачу и просит назвать сроки и цены;
2. подрядчики называют сроки и цену и берут проект;
3. начинаются работы по проекту, и что-то идёт не так;
4. к дедлайну нужного результата нет, все недовольны. Но проект надо доделать.

И эта проблема не только у аутсорсеров — такая же динамика есть и во многих продуктовых компаниях.

Почему так происходит?

- 💼 заказчики живут в реальном мире: если продукт не начнет продаваться или решать другие задачи вовремя, то экономика бизнеса не сойдется и можно закрываться — поэтому они требуют четких сроков и смет;
- 🙏 подрядчики вынуждены комититься в сроки и деньги без детальной проработки проекта. Иначе проект возьмет более сговорчивый конкурент, и команда останется без зарплаты;
- 🛠️ разработчики в команде мечтают работать над сложными проектами уровня Яндекса, но вынуждены пилить такие кривые задачи, как будто их ставили некомпетентные дураки.

На самом деле все хотят как лучше.

Одна из причин проблем — устойчивая иллюзия, что разработка — это простой процесс: берешь задачу и составляешь по ней инструкции для машины на подходящем языке программирования. Такая по сути механическая работа.

Почему это иллюзия?
Потому что разработка — это перевод очень нечетких хотелок и смутных желаний заказчика в супер строгий, не допускающий никакого двойственного толкования язык программирования. Это как с мыслями: всё очевидно, пока крутишь их в голове. Но стоит сесть и попытаться записать их, как выходит полная хрень.

(Этот пост я написал с третьей попытки, а потом понял, что потребуется целая серия постов. Так что я знаю, о чём говорю.)

💡 Для того чтобы управлять сроками, качеством и стоимостью разработки, нужно действовать контринтуитивно: уметь находиться в состоянии неопределенности, выдерживать её — и методично её прояснять.

На старте проекта бессмысленно требовать от заказчика четкости: вообще самое плохое, что можно сделать — это заставить его написать техническое задание (если он умеет писать ТЗ — то он и программирует неплохо). Вместо этого мы вначале 70-90% времени работаем исследователями — разбираемся, какую бизнес-задачу заказчика решаем и какие ресурсы и ограничения у нас есть.

Следующим постом хочу поделиться, как мы проясняем задачу. Но для этого важно сначала признать тот факт, что прояснить задачу заказчика сложнее, чем кажется на первый взгляд.

Как запускать проекты без жиры и прочей скукотени? Набрасываем с Федей на вентилятор и делимся основными принципами в честь сдачи проекта одному из клиентов.

Basecamp теперь бесплатен для фрилансеров, студентов, семей и личных проектов.

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

Basecamp — не идеальный инструмент. В нем нет канбан доски как в трелло, в которой удобно двигать задачки по статусам от «идея» до «готово». В нем нет кастомных представлений как в жире, в которых удобно посмотреть все iOS-баги, находящиеся в тестировании и назначенные на определенного человека. В нем нет мощного чата, как в слеке (ох как хочется затегать группу!). В нем нет красивого редактора, как в Notion, даже таблицу в задачу не заведешь. В нем нет древовидных комментариев, как в жире и Confluencе, а ведь так хочется ответить на определенный комментарий в треде). И уж конечно это не супер футуристичная бесконечная коллаборативная доска как Miro.

Любым инструментом можно поддержать практически любой процесс разработки. Разница в том, какое поведение инструмент поощряет, а какое — наказывает, делает неудобным. В этом плане я доверяю создателям Basecamp.

Я хочу вести разработку как создатели Basecamp — качественно, стабильно, интересно, с уважением ко всем участникам процесса. Мне интересна тема ответственности и в Basecamp она очень важна.

Если вам стало интересно, как это — вот несколько книг, объясняющих их подход:
- методология разработки — Shape Up;
- одна из главных книг про удаленную работу — REMOTE;
- как не сгореть на работе — It Doesn't Have to Be Crazy at Work!

Рекомендую.

Мы в Медузе уверенно программируем (и управляем разработкой), когда есть четкая постановка задачи — понимание, описание, макеты, тестовые данные и прочее.

Создаешь трелло доску со столбцами «описание», «разработка», «тестирование», «готово». Заводишь в неё все задачи. Даёшь внутри ссылки на .sketch-файлы. Созваниваешься перед началом проекта, обсуждаешь его голосом. Дальше постоянно контролируешь результат. Главное не забыть, что хотел получить в конечном счете.

Меня беспокоит этап, когда разработка формально ещё не началась. Собрать требования, разобраться в документации, разбить проблему на меньшие части, понять, что мы можем себе позволить, а что нет — всё это большая работа. В ней участвует не только разработка, но и дизайнеры и редакция. Сейчас эта работа делается ad-hoc, без «единого источника правды». Из-за этого возникает несколько связанных между собой проблем: 1. сложно оценить объем работы (сколько было/сколько сделано/сколько осталось) 2. сложно её делегировать (делать вместе) и делиться результатом 3. задачи теряются и забываются.

В такой формулировке, решение очевидно — использовать на этом шаге разработки те же инструменты, что и для основного программирования/тестирования. Уложить всё в трелло, разбить на задачи, назначить ответственных, вести переписку внутри.

Попробуем сделать это с несколькими следующими проектами. Расскажу потом, что получилось.

Спасибо большое Боре Горячеву, что заметил проблему и указал на решение.