Пост о том, как отрастить третий глаз или долгосрочное планирование IT проектов.
Внимание!!!
Это очень сложная магия и придется осилить многабукаф…
Если что – я предупредил.
Часть первая.
Грабли не спят.
Лифт поднял его на последний этаж. Он открыл окно. Высунул голову наружу. И смотрел на ночные бесчувственные огни. Уже было холодно, но он не обращал на это никакого внимания.
Нерешенные проблемы комом стояли в горле. Осколки разрушенной карьеры резали глаза. Слезы-самоубийцы прыгали без парашютов со стометровой высоты.
Это был первый в его жизни IT проект. И он его провалил. Месяц до сдачи, а работе не видно конца.
Он ненавидел криворуких программистов. Которые плодили баги один за другим, но уходили ровно в 18.00.
Он ненавидел ленивых тестировщиков. Которые постоянно смотрели ютуб и не были в состоянии воспроизвести ошибки для программистов.
Он ненавидел дизайнера. Который перерисовывал свои интерфейсы снова и снова.
Он ненавидел сам себя. За бессилие и незнание, как справиться с этой ситуацией…
…11-ю месяцами ранее.
Жизнь – хорошая штука! Молодой, самоуверенный. С вентилятором вместо языка. Его только что назначили главным менеджером проекта. Вторая встреча с заказчиком прошла еще лучше первой.
ТЗ было написано. Команда собрана: 4 программиста, 2 тестировщика и 1 дизайнер. Один работает над базами данных. Второй пишет серверный код. Третий и четвертый начинают параллельно делать фронтенд двух подсистем.
Осталось определиться со сроками и бюджетом.
Он пообщался с самым авторитетным программистом и решили, что всю работу можно без труда сделать за 10 месяцев. Для надежности он прибавил еще .
Всего год разделял его от всеобщего признания и кучи бабла в виде бонусов.
Он отдал ТЗ программистам. Те с криками «Ну теперь то мы точно продумаем всю архитектуру и сделаем все по уму», ринулись писать код. Тестировщики прочитали ТЗ и уселись смотреть ютуб в ожидании версий для тестирования. Дизайнер начал рисовать мудреные интерфейсы, размышляя над удобством пользователей. И как все оценят его прогрессивные задумки.
Одним словом, в самый же первый день было сделано всё возможное, чтобы провалить проект.
Часть вторая.
11 шагов к прочному фундаменту успешного проекта.
Давай я вкратце опишу, что же все-таки надо было сделать. Чтобы не было мучительно больно, за невинно убиенный продукт.
1. Определяем процессы разработки. Хочешь – скрам, хочешь – канбан, хочешь – что хочешь, но ты должен четко понимать какие будут в команде процессы на первых этапах и в какую сторону их совершенствовать.
Процессы «Пиши код, блеять» – железобетонный путь к краху всего и вся.
2. Программисты должны быть унифицированы и делать все части проекта сообща!
Работники – такие тварюки, которым присуща одна очень подлая черта. Они могут уволиться. Да-да, печальные известия: рабство отменено…
И чтобы вся работа не встала, из-за того, что единственному, кто разбирается в серверном коде предложили вкусные печеньки в соседней конторе, должна быть взаимозаменяемость.
Если этот пункт не выполнить, всё наше гениальное планирование может накрыться медным тазом. А по закону Мёрфи, если оно может накрыться, то… ну тебе понятно…
3. Bus factor. Если ты думаешь, что хватит четырех программистов для выполнения всех сроков, их должно быть, как минимум, пять. Бас фактор – сколько человек из команды может сбить автобус, чтобы вся работа не встала.
Если он равен одному, у меня для тебя плохие новости…
4. В команде должен быть аналитик. Нет, сам ты не можешь быть аналитиком. Нет, главный программист не может быть аналитиком. Даже и не думай - тестировщик тоже аналитиком быть не может! В команде должен быть аналитик!!!
Если это не попил бабла, то заказчику никогда не похуй на результат. Аналитик должен общаться с заказчиком непрерывно. Демонстрировать результаты. Получать обратную связь и вносить коррективы.
Он должен четко описывать юзер стори для программистов и следить за приоритетами. Очень важно! Юзер стори – наше секретное зелье, которое отращивает третий глаз!
5. Тут должны быть пункты с пятый по 11-й, но давай лучше поговорим подробней про юзер стори и стори поинты. Ведь именно они отращивают третий глаз…
Итак, юзер стори. Это маленькое описание одной функции которую может выполнить юзер и получить какой-то профит. Если в нашей системе есть несколько ролей, то мы обязательно указываем роль. Указываем что делает юзер. Указываем (обязательно, указываем, блеать!!!!) профит, который получает юзер.
Они звучат примерно так. Я, как пользователь вконтакта, хочу редактировать адрес своей странички, чтобы мои поклонники отличали мою страничку прямо при поиске в яндексе.
Если лень указывать профит – убей себя ап стену. Прямо сейчас. Если кому-то и «так понятно» зачем редактировать адрес. Или «так заказчик сказал». То надо ОБЯЗАТЕЛЬНО!!!! выяснить, зачем оно надо и почему он так сказал. Это пиздец как важно!!! И вот почему…
«Ходить по воде и писать софт по ТЗ легко… если они заморожены…»
Факт состоит в том, что требования меняются. Не потому, что заказчик дебил и не знает, чего он хочет. А потому, что это естественный процесс осознания своих потребностей.
Заказчик никогда не хочет никаких кнопок и отчетов. Заказчик хочет денег. И он предполагает, что если Вася вместо 5-и часов ручного составления отчетов будет его делать одним нажатием клавиши за 1 минуту, то Колю и Петю можно будет сократить и сэкономить на их зарплатах.
И в процессе разработки мы вместе с заказчиком постоянно трудимся нам выяснением, как можно помочь юзерам и сократить время их работы.
И требования из головы заказчика выходят в виде профитов. И надо понимать, что хочет в итоге получить заказчик.
Зачастую возникают ситуации
-А как этой кнопкой получить этот профит? Для этого же она нужна была!
-Ничего не знаю. Написано было сделать кнопку. Я ее делал 3 дня и 3 ночи и теперь она готова. И ежу было понятно, что этот профит нельзя так получить. Вот 100 причин… А сделать то, что ты хочешь, можно было и за час…
Грамотная юзер стори рубит такие непонимания на корню и не отдаляет заветные сроки реализации проекта. Есть еще миллион причин, почему в описании юзер стори важен профит. Но вполне хватит и этих.
Стори поинты. Что это и зачем они нужны.
У каждой такой хотелки есть сложность реализации. Что-то запрограммировать можно за час, а на что-то может уйти месяц. И если час мы еще можем оценить, то месяц на это уйдет или 2 – заранее сказать очень сложно.
Да какой месяц. Оценка в несколько дней уже будет знатным звиздежом. Поэтому мы оцениваем не в часах/днях, а в некоторых абстрактных стори поинтах. Существует стандартный ряд: 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Мы выбираем самую простую юзер стори и условно оцениваем ее в 1. Потом берем самую сложную и условно оцениваем ее в 100. Все остальные оцениваются в терминах «сложнее, чем вон та на 20, значит 40» и «примерно такая же, как вон та на 13, значит и тут 13».
Никаких 60 или 80!!! Это желание надо давить в зародыше. Чем сложнее стори, тем больше погрешность. И такая точность – это ложь, пиздежь и провокация. В первую очередь самому себе.
Через некоторое время у нас накапливается список выполненных и оцененных юзер стори. И мы уже знаем сколько времени понадобилось на выполнение каждой.
И теперь гениальный вывод из всего написанного выше.
Чтобы узнать сколько нам осталось делать проект в месяцах, нам надо просто и легко посчитать сколько времени уходило на один условный стори поинт до этого. И сколько в сумме стори поинтов предстоит еще сделать.
На первый взгляд может показаться, что точность всего этого будет ужасающей. Но поверь, это не так. Практика показывает, что таким образом можно планировать на многие месяцы вперед и получать точность в пару недель.
P.S.
И это мы разобрали только один шаг… ты еще хочешь начинать новый проект?
P.P.S
Если хочешь получить чек лист с остальными пунктами и их детальный разбор без регистраций и смс, поставь лайк и напиши в коментах о чем тебе было бы интересно почитать и стоит ли мне вообще продолжать эту тему
