Как стать автором
Обновить
25
0
Александр Мороз @alexandrmoroz

Предприниматель, founder & CEO @ Moroz Team

Отправить сообщение

Конечно, ресурсы надо отслеживать и планировать, это понятно. Я за то, чтобы по возможности не взваливать вопросы ресурсного планирования на разработчиков. Они не могут и не должны точно оценивать в часах. Но оценку вообще они должны давать, без этого никуда. Поэтому придумали эту хитрость с оценкой качественной (просто-сложно-нереально) вместо количественной. А количественная (уже в целях ресурсного планирования) появляется в отчетах, которые в хороших системах делаются автоматически. В том числе и форму Т-13 заполнить и т.д., чтобы и бухгалтерия была довольна, и заказчику можно было бы объяснить смету, если ему так привычнее. Хитрости эти придумали очень давно, называются они Agile, Scrum и иже с ними. И заказную разработку тоже можно так делать. Вопрос в целесообразности, готовности команды и бизнеса к этому. Редко кто сразу начинает именно так работать. Обычно это долгий и тернистый путь)
Вы продвинулись не мало за несколько лет. У вас есть отчетность, вы планируете — большинство даже этого не делают.

Никакой слежки за сотрудниками – это принципиальная позиция. Считаем эффективность по скорости команды в целом: есть такое понятие velocity, за единицу расчёта берем story point. Это намного гибче, проще и в итоге точнее получается, чем считать часы. Разработчик участвует в оценивании задач на planning poker. Оценки даём качественные, а не количественные. Для гибкого планирования этого достаточно. И в итоге ошибок гораздо меньше.

У сервиса Аванплан есть импорт из Jira и Trello, в том числе импорт оценок задач в SP. Все проекты и задачи импортируются быстрее, чем за минуту (мы переезжали из Redmine c 2500 тыс задач). Есть веб-версия и мобильное приложение iOS, Android. Есть оценки в сторипойнтах, есть расчёт скорости команды, есть прогнозы по дате завершения на основе этой скорости, удобные дашборды не для галочки, а исходя из помощи в планировании и отслеживания прогресса.

Самое полезное для меня лично — это я смог импортнуть свои личные задачки из Trello, а рабочие из Redmine и теперь на одном дашборде мне подсказывают успею ли я до конца недели все свои задумки сделать как по работе, так и по дому. Раньше я пытался это как-то в OmniFocus сводить. Но у него не было интеграции именно с трекерами задач.

Покер проводим в Retrius — также российская разработка. Там же можно провести ретро или мозгоштурм при необходимости. Заставляет не расплываться мыслью по древу и придерживаться повестки. Собрания у нас теперь в два раза короче получаются. Народ доволен.

Кайтен неплох для тех, кто привык именно к Trello. Но пользоваться трелло именно для разработки как по мне — один из первых этапов зрелости команды. С ростом зрелости и опыта уже слишком тесно становится в трелло.

Ждём статью, как вы работаете, почему ваша команда классная, какие кейсы вы решаете и т.п.)

Да, за хорошее качество приходится платить. Я к тому, что крупный != качественный априори. Во всех сегментах есть свои плюсы и минусы. Кому надо завтра и одну страничку - тот идет к фрилансеру. Вы же навряд ли возьметесь за такой копеечный заказ. Кому надо надежность, синие печати, какие-то гарантии на бумаге, тот придёт к вам. Разные ЦА, разный рынок - разные цены. Вы же не конкурируете с фрилансерами? Или думаете, что вам нужны заказы, которые у них?)

Мне кажется, что между фрилансером, мелкой и крупной студией разница в основном только в цене. С фрилансером выше риски по срокам только. Но если нанять двух-трех на одну задачу, то выходит дешевле всё равно.

В мелкой студии может оказаться внезапно качественнее и быстрее, чем в крупной.

Единственное оправдание высокой цены у крупняка - это необходимость кормить огромный штат, чтобы всегда кто-то был наготове, чтобы не упустить заказ. Так что желание крупной студии продать любой ценой - оно очень заметно обычно))) А у среднячков всегда очередь из заказчиков))

Вот все и метаются как могут. А надо не жадничать, стремиться к высотам, но при этом трезво оценивать обстановку (см. От хорошего к великому - Джим Коллинз)

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

Я шёл по пути от простого к сложному. На данный момент успешно использую все перечисленные методы в зависимости от сложности проекта и нужной точности расчётов. Но мы не делаем голый аналитический расчёт сразу. Первый - всегда прикидочный экспертный. Дальше по мере появления декомпозированных задач, которые мы в состоянии оценить, то мы их оцениваем качественно (легкая / сложная / очень сложная) и планируем в спринт только относительно простые задачи. Сложные отправляются в бэклог для уточнения / проработки. Если проект - это продукт, то такие задачи могут вообще до реализации не добраться. А для заказов берём время на исследование из пула на исследования.

Из приятного - такой подход с качественной оценкой вместо количественной оказался точнее в итоге. Процесс оценки (планинг-покер) проходит очень быстро, никто не расстраивается, что оценил задачу в 1 час, а делал её 8, потому что 1 сторипойнт у нас - это от 1 часа до 1 дня как раз.
Мотивация не падает, все довольны. И руководитель проекта и разработчики перформят и намного чаще укладываются в свою оценку.

В разработке ПО проектирование в худшем случае занимает 30% времени. И это уже полностью закрытый этап эскизного и технического проекта. Обычно достаточно 10% Не сомневаюсь, что можно раздуть и до 150%-1500% от времени фактической реализации))

В итеративной разработке (читай Agile) в абсолюте на спринт это 1 день из двух недель на планирование.

Есть, конечно и форс-мажоры и другие обстоятельства. Но в организациях уровня развития выше 3 по CMMI так и работают. Время - деньги.

Согласен, что делать по книжкам очень сложно, особенно, когда нет поддержки со стороны руководства и команда не верит в теорию и чужой опыт)
Разные организации находятся на разных уровнях развития. Мы за то, чтобы помогать развиваться всем, кому можем (с учётом нашего уровня развития) и самим тоже развиваться.

Нет ничего плохого, если постепенно команда будет тратить меньше времени на проектирование и меньше ошибаться в сроках, используя проверенные методики.

Верно. Самое сложное - это декомпозировать, а если невозможно, то исследовать такие задачи, про которые ничего неизвестно.
Такие задачи можно изучать так:
1. Берем Х часов (обычно достаточно 1-2 часа) на исследование. Гуглим, ищем источники
2. По результатам Х-часового исследования возвращаемся с полученной информацией и более чётким планом. В этот момент у руководителя и команды уже достаточно данных, чтобы принять решение о приоритете и дальнейших шагах по этой страшной задаче, которая после исследования может быть и не такая уже и страшная

Про сроки и дедлайн.
В идеале - это когда расчетный срок учитывается при выставлении дедлайна.
Если так случилось, что дедлайн уже выставлен, а никакой расчёт не проводился, то можно только пособолезновать такому мертворождённому проекту)
В таких случаях режут функциональность обычно. Бывают попытки увеличить скорость команды за счёт найма и т.п., но такие решения приводят к уменьшению скорости команды, потому что не учитывается теория управления про издержки управления.

В статье про это упомянуто в целом про "Способ 3. Расчётный".

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

Так что да, это самый точный способ (независимо от методики), но самый затратный

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

При большом количестве задач ошибки форсмажорные автоматом нивелируются.
Задачи нужно оценивать качественно, а не количественно.
При оценке в сторипойнтах или "попугаях", описанных проблем гораздо меньше.
Например, в приведённом выше примере оценка в 1 сторипойнт включает в себя разброс фактического времени, потраченного на задачу, - от получаса до 8 рабочих часов.

В общем, если считать в часах, то и точность должна быть в часах, т.к. измерение должно попадать в погрешность размерности шкалы. А точность до часа в управлении проектами не нужна. Но если требовать оценивать в часах (потому что у ПМа "программа только так считает") - то и получаем саботаж планирования. Даже может быть неумышленный.

Никогда разработчик не знает точно в часах. Зато может и должен знать на уровне "простая, сложная, очень сложная, и нифига непонятно как это вообще делать". Если не знает, то надо звать старшего)
Дальше уже задача тимлида или ПМа не допустить в план задач с оценкой выше "сложная" или "простая". Для этого существует проектирование, декомпозиция и ещё куча других способов.

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

Также не помешает упомянуть про разные уровни зрелости организаций. Например, в организациях 4-5 уровня (из 5) вопросы, затронутые в статье и в комментариях вообще не возникают))

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

Хороший PM должен и умеет считать с вероятностью 95% - см. методику PERT, например.
Только есть нюанс — среди всех PM в мире таких ребят от силы 5% )))
В общем, всё сводится к опыту, знаниям и т.п. Не каждый инженер может построить ракету-носитель. А если и сможет, то не факт, что она взлетит выше 30 км. Хотя при этом есть ракеты, которые вполне себе летают уже много лет без особых проблем.
Театр в Сиднее когда строили, то бюджет и сроки в разы превысили. Но опять же, есть примеры больших строек, закончившихся в срок и даже с опережением.
При этом всегда успешных проектов мизер по сравнению с "обычными".

И это не погрешность измерений или статистики, а закономерность, которая складывается из опыта и знаний проектной команды.

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

Спасибо, Миша! В своих проектах пробую этот подход.
Похоже, появился менее костыльный генератор с поддержкой null-safety: dart-dio-next: https://openapi-generator.tech/docs/generators/dart-dio-next

Ну, вот я в прошлом году отсобеседовал несколько десятков разработчиков на бэк, фронт. Кандидатов в пару раз больше было. И среди них было гораздо больше половины, кто хотел зарплату из верхней части медианы. Вилку нашу мы не публиковали. ЧЯДНТ?

С крайними перцентилями и медианами по компаниям уже ближе к реальности, спасибо)
А медиана — это без интерпретации — всё та же средняя по больнице. Нужны сектора с привязкой и проекциями. Типа: крутые мидлы получают с среднем 200, а кому не повезло, то 100. Чтобы польза была от исследования практическая. Например, в бизнес-модель заложена текучка, то можно в первых двух четвертях "работать" по кадрам. Если нужны спецназовцы, то рассчитываем выложить выше 90 перцентиля.

Долго не мог понять, почему эта статистика никак не вяжется с жизнью вокруг.
Теперь есть ответ: мы нанимаем квалифицированных сотрудников. Таковых среди всех кандидатов обычно не больше 20%.

Итого, реальные зарплаты квалифицированных работников будут начиная с 80 перцентиля. Есть такая инфа? Вангую, что мидлы там будут по 200-250, а синьоры за 250-350 и выше.

Остальные "статисты" никому не интересны. Смысл нанимать товарища синьора за 100? Его либо никуда не берут, либо через полгода он попросит в два раза больше или уйдёт. А ФОТ уже утвержден на него.

А подобная статистика делает жизнь технических руководилелей только сложнее. Как мне объяснить начальству, что ФОТ мне нужен выше, если уважаемая Хабр-Карьера публикует такие отчеты...

Ну и к слову, что на мидла PHP вообще кандидатов дешевле 150 не было в мск ещё год назад. Инфа за один из банков.

Ага)) Но это же надо напрячься. А так циферки свёл и всё тут.
Вот народ в комментах инфу из реального мира напишет, может быть.

Мск, семья из двух человек, тратим 250к, почти не в чем себе не отказываем. Немного остается на ипотеку, оба работаем. Обеды в ресторанах и готовая еда — половина бюджета на еду.
Есть профстандарт, есть программы обучения (неплохая в Плехановке выпуска 2018 г.), есть Вигерс, есть OpenUP, Agile, SWEBoK.

Но, к сожалению, в большинстве компаний роль аналитика самая несчастная в плане набора задач. Т.к. аналитик — один из самых умных членов команды (не в обиду разработчикам) и при этом в идеале с высоким EQ, а также зачастую гиперответственный, то на него вешают всё что только можно.

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

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

Потом общаемся с таким человеком-оркестром, и он вообще всё знает про разработку, про микросервисы, схему базы может нарисовать, SQL на всех диалектах, XMLQuery и всё вот это вот. А кто такой Вигерс он даже не в курсе. Какие виды требований бывают и зачем, тоже может не знать. При этом старший или ведущий аналитик.

Как считаете, что делать дальше в таком случае? Переучиваться или продолжать работать в таких нишах дальше?

Информация

В рейтинге
Не участвует
Откуда
Казань, Татарстан, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Fullstack Developer, Chief Technology Officer (CTO)
Lead
От 500 000 ₽
Python
RESTful API
PostgreSQL
OOP
Flutter
Development of mobile applications
iOS development
Dart
Client-server applications
Clean Architecture