Методология как конструктор
Прочитал хороший текст для тимлидов-программистов «Методология как конструктор». Полезно для прочтения руководителям команд любых профессий, но с техническим складом ума.
1. Все методики основаны на страхе. Разные страхи приводят к разным методологиям. Страх переплатить ведет к найму дешевых разработчиков, которых просто менять — это SCRUM. Страх ошибки приводит к ГОСТам или RUP с кучей формализованных документов.
2. Обычно бизнес хочет все и сразу. Когда собираете требования — придерживайтесь предположения, что «пациент всегда врет». Когда бизнес хочет все, он врет. Попытайтесь понять, что бизнес действительно хочет и попытайтесь ему это продать. Это не самый стандартный для тимлида набор умений. Но если вы не умеете выяснять реальные требования бизнеса, то необходимо найти человека, который умеет.
3. Каждый сотрудник имеет право спросить про любую задачу: зачем ее делать, зачем делать именно так и кому она вообще нужна? Как только начинаете спрашивать «зачем» на всех уровнях, включая бизнес, в разы уменьшается объем задач и так же увеличивается мотивация. Люди понимают смысл работы и выполняют ее быстрее и экономнее, срезая углы.
4. Не создавайте универсальное решение, пока нет трех разных примеров. Если проектируете три разных самолетика, то не можете сразу по одному из них написать корректный класс, который он представляет. Это решение и для разработки — не стройте универсальную интеграцию с контрагентами, пока нет трех разных интеграций и нет понимания, где они разные.
5. Чек-лист — это ритуал, который разгружает мозг и дает возможность в 3 часа ночи сделать выкладку на продакшн и его не уронить. Чек-лист позволяет не думать.
6. Вообще весь Agile — это про увеличение нормы эксплуатации разработчиков, потому он и востребован бизнесом. Бизнесу нравится, что люди работают быстрее и дешевле. Если бы у программистов был профсоюз, то Agile, SCRUM и XP запретили бы.
7. Review before code. Регулярно слышу, как человеку дали ответственность за большую фичу, а он сделал не то и надо переделывать. Прежде, чем писать код, сотрудник в Jira описывает план решения задачи на две строки или два абзаца текста. Такая практика позволяет тимлиду или архитектору быть в курсе всех изменений в большом проекте. Он читает не кривой код, а два абзаца о том, что вообще происходит в системе, и быстро ловит людей за руку.
8. Создание методики — это инженерная задача. Ровно такая же, как программирование и проектирование модулей системы. Именно так к этому и подходите. Вы умеете хорошо решать инженерные задачи — так используйте все свои знания в этой новой практике.
9. Главное достоинство программиста — его лень. Постройте процессы так, чтобы люди тратили на них еще меньше времени, и разработчики первыми побегут их внедрять. Если люди не стремятся внедрять процессы, значит они не поняли зачем.
Источник:
https://habr.com/ru/company/oleg-bunin/blog/456514/Крутейший/
