Очень хорошая статья, но позволю себе сделать несколько замечаний: 1. Довольно банальное замечание, но "Ломается у хороших программистов" - потому что они что-то делают, не ломается только у тех, у кого ничего нет и они ничего не делают))) "Хороших" отличает то, что у них ломается реже на единицу функционала (не на строчку кода) и самое главное, что у хороших молния не бьет два раза в одно место, отсюда замечание №2 2. В статье довольно часто упоминается, что это какие-то внешние факторы что-то сломали или являлись причинами сбоев. Это действительно так и с кейсами не поспоришь, но упущено главное следствие - что делать, когда такое произошло ("менеджер сказал сделай костыль, а то уволю", "соседняя команда дала сумашедший RPS", "требования поменялись в процессе разработки" и т.д.). Хорошего программиста отличает умение писать премортемы и постмортемы, проводить ретроспективы по крупным задачам/проектам, или по простому учится на ошибках) Тут есть очень тонкая грань - как только ты говоришь что виноват внешний фактор, то перестаешь подстраивать процессы и вероятность повторения стремится к 100%, если же вместо "почему так получилось" задаваться вопросом "а как можно было предотвратить", то все улучшается прямо на глазах)) Все эти не сложные практики позволяют подстраивать процессы под текущие реалии, оставаться гибкими в изменчивых внешних условиях. В конце концов, если руководство совсем невменяемое, то по статистике понять, что теряешь свой скилл и перейти в другую компанию. 3. Мне очень понравился термин "золотая шестеренка", это прямо бомба и теперь буду его использовать, но "нужно опасаться работать с «золотыми шестерёнками». Они всегда вылетают" - звучит как "я не буду с вами работать, вы слишком хороши для нашей компании"))) Лично я утверждаю, что нужно наоборот как можно больше золотых шестеренок, вместе они работают только лучше. Но золотые шестеренки должны быть не только на на позициях инженеров, а и в менеджменте, вплоть до владельца компании. Именно такие компании делают прорывные продукты и изменяют рынок. Без золотых шестеренок компания становится забюрократизированной, так как новшеств она уже не производит, некому, поэтому все идет в сторону стандартизации, структурирования, фиксирования, комитетов и других матерных слов. На самом деле работать с "золотыми шестеренками" достаточно просто, говорю это на довольно большом опыте. Необходимо просто выделить в золотой шестеренке главное в чем он/она хороши, они всегда немного "перекособечены" (отлдичный разраб, плохие софтскиллы, отличный менеджер, ничего не понимает в ИТ и так далее), при этом отличает их зачастую фанатичный свет в глазах и заставлять заниматься их тем, что им не нравится - верный шаг к тому чтобы их потерять. Поэтому просто даешь такой шестеренке фронт работ, который вызывает наибольший интерес и подстраиваешь процессы, чтобы не было негативных факторов, пусть даже полуиндивидуально именно под эту шестеренку. Это даст гигантский буст продукту и команде, ведь если золотая шестеренка среди команды разработки, то именно на него будут равняться остальные, он будет движетелем технологий. Если шестеренка в менеджменте, то его команда будет показывать лучшие результаты и так далее. Так что я бы не опасался работать с ними, а наоборот старался работать именно с ними))
Очень хорошая статья, но позволю себе сделать несколько замечаний:
1. Довольно банальное замечание, но "Ломается у хороших программистов" - потому что они что-то делают, не ломается только у тех, у кого ничего нет и они ничего не делают))) "Хороших" отличает то, что у них ломается реже на единицу функционала (не на строчку кода) и самое главное, что у хороших молния не бьет два раза в одно место, отсюда замечание №2
2. В статье довольно часто упоминается, что это какие-то внешние факторы что-то сломали или являлись причинами сбоев. Это действительно так и с кейсами не поспоришь, но упущено главное следствие - что делать, когда такое произошло ("менеджер сказал сделай костыль, а то уволю", "соседняя команда дала сумашедший RPS", "требования поменялись в процессе разработки" и т.д.). Хорошего программиста отличает умение писать премортемы и постмортемы, проводить ретроспективы по крупным задачам/проектам, или по простому учится на ошибках) Тут есть очень тонкая грань - как только ты говоришь что виноват внешний фактор, то перестаешь подстраивать процессы и вероятность повторения стремится к 100%, если же вместо "почему так получилось" задаваться вопросом "а как можно было предотвратить", то все улучшается прямо на глазах)) Все эти не сложные практики позволяют подстраивать процессы под текущие реалии, оставаться гибкими в изменчивых внешних условиях. В конце концов, если руководство совсем невменяемое, то по статистике понять, что теряешь свой скилл и перейти в другую компанию.
3. Мне очень понравился термин "золотая шестеренка", это прямо бомба и теперь буду его использовать, но "нужно опасаться работать с «золотыми шестерёнками». Они всегда вылетают" - звучит как "я не буду с вами работать, вы слишком хороши для нашей компании"))) Лично я утверждаю, что нужно наоборот как можно больше золотых шестеренок, вместе они работают только лучше. Но золотые шестеренки должны быть не только на на позициях инженеров, а и в менеджменте, вплоть до владельца компании. Именно такие компании делают прорывные продукты и изменяют рынок. Без золотых шестеренок компания становится забюрократизированной, так как новшеств она уже не производит, некому, поэтому все идет в сторону стандартизации, структурирования, фиксирования, комитетов и других матерных слов. На самом деле работать с "золотыми шестеренками" достаточно просто, говорю это на довольно большом опыте. Необходимо просто выделить в золотой шестеренке главное в чем он/она хороши, они всегда немного "перекособечены" (отлдичный разраб, плохие софтскиллы, отличный менеджер, ничего не понимает в ИТ и так далее), при этом отличает их зачастую фанатичный свет в глазах и заставлять заниматься их тем, что им не нравится - верный шаг к тому чтобы их потерять. Поэтому просто даешь такой шестеренке фронт работ, который вызывает наибольший интерес и подстраиваешь процессы, чтобы не было негативных факторов, пусть даже полуиндивидуально именно под эту шестеренку. Это даст гигантский буст продукту и команде, ведь если золотая шестеренка среди команды разработки, то именно на него будут равняться остальные, он будет движетелем технологий. Если шестеренка в менеджменте, то его команда будет показывать лучшие результаты и так далее. Так что я бы не опасался работать с ними, а наоборот старался работать именно с ними))