Комментарии 29
А заплатили им как за шестерых? Я хочу напомнить, что от повышения производительности, выигрывает в основном owner, а не worker
Если им платили как за троих, а работали они за шестерых, то выходит, что они сами себя на*бали.
А заплатили им как за одного. Здорово, правда?
"три разработчика сделали работу за шестерых и в два раза быстрее" - тут четерехкратное повышение производительности.
В данном случае физически сотрудники продолжили работать в том же темпе. А вот за счет получения положительной обратной связи от конечных пользователей при улучшении продукта дало значительное снижение психологической нагрузки и исключило выгорание.
Получается в плюсе были Owner, Users, Workers)
Краткое содержание (для тех, кто не осилил):
Берём полный пиздец, например:
При распределении заданий на разработку не обращали особое внимание на уровень компетенции избранного разработчика и на основную сферу его компетенции, его профессиональный фокус.
Применяем ТРИЗ от Гоги Альтшуллера и ещё что-то подобное для отвода глаз, и фсио, где мы - там победа.
Как говорил Геральт: "сначала поговорим о награде". Какая в итоге, как за шестерых?
Именно за счет того, что с разработчиков снята прочая "повинность" и исключены "дергания" по "срочным" задачам, это привело к интенсификации процесса разработки. А физическая нагрузка на сотрудников осталась прежней, и была в значительной степени снята психологическая нагрузка.
Вы и ваша команда, однозначно — герои. Но дела плохи, потому что вы, похоже, не только не получили заслуженное, но и, возможно, установили новую планку ожиданий без доплаты.
Бизнес получил финансовую выгоду, а разработчики — только психологический комфорт и «спасибо». Четырёхкратный рост производительности — это не шутки, и без пропорционального вознаграждения разработчики, похоже, подешевели.
Если за это не заплатили, то это выглядит как «на*б».
Какой вид продукта разрабатывает компания?
Если белка в колесе ускоряется, колесо просто начинает крутиться быстрее.
На осуществление всех описанных изменений потребовалась 4 года.
И всё это время исправно платили зарплату? Чтоб я так жил.
Москва не сразу строилась)
Да и первый эффект от принятых решений был показан уже в течение первого года.
Каждый раз вера в успешность будущих решений росла.
Москва не сразу строилась)
Видите ли, у меня был опыт такого рода. Как-то получил проект, в котором не было:
Общего репо, код хранился на компах разработчиков, свои изменения каждый из примерно полутора десятков высылал по мэйлу руководителю, который их локально же объединял.
Никакого таск трекера, задачи ставились по мэйлу или в чате.
Тестирования как такового, каждый проверял свои изменения сам.
Промежуточных стадий, код заливался сразу на прод по FTP.
Графика релизов – они делались 2-3 раза в год, без чётких критериев готовности.
Такой вот воплощённый кошмар – и тем не менее, чтобы привести всё это в относительный порядок, понадобилось меньше месяца. Потом ещё около года, чтобы переписать весь этот говнокод (а в таких условиях иным он быть не мог). Чем можно было заниматься аж 4 года, оптимизируя работу шести разработчиков – для меня загадка. За такой срок можно и впрямь немаленькую часть Москвы построить.
Очень объемный пост и понравилось что указаны концепты и практики. Но хотелось бы увидеть еще и "подводные камни" которые были во время исполнения всея объемного плана.
Еще не совсем понял как берется 40 часовой цикл и осталось скептическое мнение об эффективности внедрения оценки трудозатрат. В наблюдении данные "системы" всегда показывают результаты менее ожидаемых.
Но все равно пост считаю неплохим "примером из учебника".
Подводные камни были, но в основном связанные с внутриполитическими особенностями, потому их освещение выходит за рамки этой статьи.
Остальные особенности принятых решений привели бы к кратному увеличению объёмов статьи, потому скорее всего посвящу отдельные статьи каждому из направлений.
Цикл разработки был взят 40 часов (неделя) только для удобства производственного подразделения. Разработчики же при выполнении работ не ориентировались на этот срок. А опирались на наиболее вероятный срок завершения и еще промежуточный период (половина срока), для лучшего контроля сроков.
Сказ о том, как три разработчика сделали работу за шестерых и в два раза быстрее