Говнокод vs идеальный код
Недавно мой товарищ и подписчик прислал мне видео https://www.youtube.com/watch?v=-R455cuPsV4 которое предложил обсудить в канале.
Видео само по себе уже содержит довольно много рассуждений на тему того надо или не надо говнокодить, стоит ли вылизывать код до перфекционизма и т.д. Так что тут уже особо в обсуждениях я каких-то новых революционных мыслей не внесу. Могу лишь выразить свое мнение по этому поводу и рассказать как эти идеи эволюционировали в моей работе.
На начальных этапах моей программистской карьеры меня метало из стороны в сторону. Начиналось всё с ужасного говнокода "и так сойдет, работает же".
Под шквалом справедливой критики я начал читать книги типа "Совершенный код", "Программист прагматик", паттерны банды четырех и т.д. Ну и конечно десятки и сотни хабрастатей и им подобных как круто писать чистый код, как необходима гибчайшая, максимально расширяемая архитектура. Ну и начал максимально вылизывать даже самые простые случаи, пихать максимальное колличество паттернов, которые я знаю, куда надо и куда не надо.
Мне казалось, что вот сейчас стало круто и идеально (на самом деле нет). Потом, поддерживая это переусложненное творение, я понял, что красота и идеальность кода не в том, чтобы напихать туда как можно больше всего, про что ты недавно прочитал.
После этого я решил поумерить свой пыл, но продолжил разрабатывать так, что "а вот тут может понадобиться изменение логики, там расширение функционала, здесь увеличится нагрузка". И это неплохой подход, но делал я так везде. Во всех проектах, во всех задачах. А реально стреляло это где-то в 20% случаев. Так осталось много мертворожденных потенциальных фич, на которые было потрачено довольно много времени. Мне надо было читать Дональда Кнута, который говорит "преждевременная оптимизация — корень всех зол". Мое мнение, что потом дооптимизировать в 20% случаев - зачастую (не всегда) проще, чем поддерживать изделие, которое излишне переусложнено в 80% случаев.
Теперь я стараюсь смотреть на проект и фичу с точки зрения не только реализации, но и бизнеса, заказчика, потенциальной эволюции требований. Со временем и опытом сердечко стало лучше подсказывать, где можно быстро наговнокодить на коленке проект, который послезавтра уже выкинут, а где нужно строить хорошую архитектуру, писать тесты, думать о вариантах развития проекта, который будет расти и поддерживаться годами.
Ну и, конечно, надо рассмотреть идеальный вариант. Как известно, самый лучший код - это код, который не написан. Так что некоторые задачи иногда стоит обдумать и обсудить с заказчиком и своим здравым смыслом. Как показывает моя практика - заказчик не всегда сам знает, что именно ему нужно и как. Он просто заносит свои идеи, формулируя это как требования, а ретивый программист бежит их исполнять. Тут помогает взгляд со стороны бизнеса и умение построить диалог, в котором и программист, и заказчик смогут понять, что же на самом деле надо и какие есть варианты реализации. Кто-то может заметить, что для таких разговоров есть ПМы, аналитики, тимлиды, а не программисты. Ну.....да. Где-то есть, где-то нет. Тут речь в целом о концепции не брать сразу под козырёк и бежать исполнять любой чих.
Вывод
Говнокод писать иногда можно и даже нужно, но и злоупотреблять им не стоит. Смотрите на сам проект, на влияние заказанной фичи на бизнес, на перспективы развития. Думайте, перед тем как делать. Не занимайтесь преждевременной оптимизацией. При возможности не писать код - не пишите, не умножайте энтропию:)
Недавно мой товарищ и подписчик прислал мне видео https://www.youtube.com/watch?v=-R455cuPsV4 которое предложил обсудить в канале.
Видео само по себе уже содержит довольно много рассуждений на тему того надо или не надо говнокодить, стоит ли вылизывать код до перфекционизма и т.д. Так что тут уже особо в обсуждениях я каких-то новых революционных мыслей не внесу. Могу лишь выразить свое мнение по этому поводу и рассказать как эти идеи эволюционировали в моей работе.
На начальных этапах моей программистской карьеры меня метало из стороны в сторону. Начиналось всё с ужасного говнокода "и так сойдет, работает же".
Под шквалом справедливой критики я начал читать книги типа "Совершенный код", "Программист прагматик", паттерны банды четырех и т.д. Ну и конечно десятки и сотни хабрастатей и им подобных как круто писать чистый код, как необходима гибчайшая, максимально расширяемая архитектура. Ну и начал максимально вылизывать даже самые простые случаи, пихать максимальное колличество паттернов, которые я знаю, куда надо и куда не надо.
Мне казалось, что вот сейчас стало круто и идеально (на самом деле нет). Потом, поддерживая это переусложненное творение, я понял, что красота и идеальность кода не в том, чтобы напихать туда как можно больше всего, про что ты недавно прочитал.
После этого я решил поумерить свой пыл, но продолжил разрабатывать так, что "а вот тут может понадобиться изменение логики, там расширение функционала, здесь увеличится нагрузка". И это неплохой подход, но делал я так везде. Во всех проектах, во всех задачах. А реально стреляло это где-то в 20% случаев. Так осталось много мертворожденных потенциальных фич, на которые было потрачено довольно много времени. Мне надо было читать Дональда Кнута, который говорит "преждевременная оптимизация — корень всех зол". Мое мнение, что потом дооптимизировать в 20% случаев - зачастую (не всегда) проще, чем поддерживать изделие, которое излишне переусложнено в 80% случаев.
Теперь я стараюсь смотреть на проект и фичу с точки зрения не только реализации, но и бизнеса, заказчика, потенциальной эволюции требований. Со временем и опытом сердечко стало лучше подсказывать, где можно быстро наговнокодить на коленке проект, который послезавтра уже выкинут, а где нужно строить хорошую архитектуру, писать тесты, думать о вариантах развития проекта, который будет расти и поддерживаться годами.
Ну и, конечно, надо рассмотреть идеальный вариант. Как известно, самый лучший код - это код, который не написан. Так что некоторые задачи иногда стоит обдумать и обсудить с заказчиком и своим здравым смыслом. Как показывает моя практика - заказчик не всегда сам знает, что именно ему нужно и как. Он просто заносит свои идеи, формулируя это как требования, а ретивый программист бежит их исполнять. Тут помогает взгляд со стороны бизнеса и умение построить диалог, в котором и программист, и заказчик смогут понять, что же на самом деле надо и какие есть варианты реализации. Кто-то может заметить, что для таких разговоров есть ПМы, аналитики, тимлиды, а не программисты. Ну.....да. Где-то есть, где-то нет. Тут речь в целом о концепции не брать сразу под козырёк и бежать исполнять любой чих.
Вывод
Говнокод писать иногда можно и даже нужно, но и злоупотреблять им не стоит. Смотрите на сам проект, на влияние заказанной фичи на бизнес, на перспективы развития. Думайте, перед тем как делать. Не занимайтесь преждевременной оптимизацией. При возможности не писать код - не пишите, не умножайте энтропию:)
YouTube
Ты должен писать плохой код
Короче, Программист, я тут задокументировал и в благородство играть не буду: выполнишь для платформы пару заданий — и мы в расчете. Заодно посмотрим, как быстро у тебя башка после этого сочного кода прояснится. А по твоей теме постараюсь разузнать. Хрен его…
👍1
Нужны ли тимлиды?
Недавно в одном канале увидел бурлящий спор на тему того, нужны ли тимлиды, можно ли без них, бирюзовые организации и т.д.
На мой взгляд тимлиды в общем случае нужны. Прямо необходимы.
Конечно в этом споре всегда можно привести какой-нибудь пример компании, где тимлидов нет, плоская структура и при этом все процессы так чётко выстроены, что всё работает как часы. Но на каждый такой пример можно привести сотню обратных, где хаос и разгильдяйство надо держать в узле специальными компетентными, ответственными людьми.
Сфера ответственности тимлида в ИТ немного размыта, но в общем случае он гарант успешной работы многих компонентов рабочей экосистемы.
Он следит, чтобы разработка шла в нужном ключе технически, чтобы без hype, cv, костыль driven development.
Следит за сроками проекта. Чтобы команда успевала вовремя, заказчик не шибко давил и т.д.
Принимает финальные решения при найме новых сотрудников. А кто ещё так хорошо определит, подойдёт ли человек в команду? Не эйчар же)
В целом смотрит за мотивацией и настроением команды. Держит руку на пульсе, так сказать.
И самое в этом главное то, что на тимлиде лежит ответственность. Он - точка входа в команду. Он тот, кто за всё это отвечает.
Когда ответственных или нет, или их много, то каждый думает "ну у меня свои дела, щас за меня Вася или Маша разберутся". А у Васи с Машей тоже дел дофига, и в итоге все забили.
У семи нянек дитя без глазу.
Хороший, инициативный, ответственный тимлид в команде может ощутимо повысить уровень производительности, счастья и дисциплины команды. Равно как и плохой тимлид может быстро испортить даже толковую команду.
Хороших вам тимлидов. А если можете обойтись без них, то я за вас искренне рад 👍
Недавно в одном канале увидел бурлящий спор на тему того, нужны ли тимлиды, можно ли без них, бирюзовые организации и т.д.
На мой взгляд тимлиды в общем случае нужны. Прямо необходимы.
Конечно в этом споре всегда можно привести какой-нибудь пример компании, где тимлидов нет, плоская структура и при этом все процессы так чётко выстроены, что всё работает как часы. Но на каждый такой пример можно привести сотню обратных, где хаос и разгильдяйство надо держать в узле специальными компетентными, ответственными людьми.
Сфера ответственности тимлида в ИТ немного размыта, но в общем случае он гарант успешной работы многих компонентов рабочей экосистемы.
Он следит, чтобы разработка шла в нужном ключе технически, чтобы без hype, cv, костыль driven development.
Следит за сроками проекта. Чтобы команда успевала вовремя, заказчик не шибко давил и т.д.
Принимает финальные решения при найме новых сотрудников. А кто ещё так хорошо определит, подойдёт ли человек в команду? Не эйчар же)
В целом смотрит за мотивацией и настроением команды. Держит руку на пульсе, так сказать.
И самое в этом главное то, что на тимлиде лежит ответственность. Он - точка входа в команду. Он тот, кто за всё это отвечает.
Когда ответственных или нет, или их много, то каждый думает "ну у меня свои дела, щас за меня Вася или Маша разберутся". А у Васи с Машей тоже дел дофига, и в итоге все забили.
У семи нянек дитя без глазу.
Хороший, инициативный, ответственный тимлид в команде может ощутимо повысить уровень производительности, счастья и дисциплины команды. Равно как и плохой тимлид может быстро испортить даже толковую команду.
Хороших вам тимлидов. А если можете обойтись без них, то я за вас искренне рад 👍
Курсы в ИТ. Инфоцыгане или польза?
Сейчас из каждого утюга вещают о том, как вас готовы научить программировать всего за N денег, и после прохождения этих чудесных курсов вы сможете зарабатывать Nx2 КАЖДЫЙ МЕСЯЦ!
Хотелось бы предупредить потенциальных жертв маркетинга, что всё немного не так, как сообщается в рекламе.
Далее последует моё личное мнение, основанное на собственном опыте (у меня его хватает) и опыте знакомых, коллег, товарищей.
Нужны ли вам курсы, чтобы "вайти в айти"?
Насколько я знаю статистику по нескольким площадкам и курсам, до конца доходит в среднем четверть. А трудоустраивается потом тоже не сильно много людей из этой четверти.
Так что если вы увидели рекламу о том, как поучитесь 2 месяца, а потом будете зарабатывать стотыщ, то прочитайте мой прошлый пост https://news.1rj.ru/str/general_it_talks/9 и крепко задумайтесь, надо ли оно вам, готовы ли вы вложить столько труда, времени и денег.
Нужны ли курсы для уже вошедших?
Я считаю, что постоянное самообразование в нашей отрасли - необходимое условие для роста и развития. Как вы это делаете, решать вам. Лично мне курсы помогают.
Тут не стоит заводить спор о том, что лучше, почитать статью на хабре, посмотреть видосик на ютубе, прочесть книгу или пройти курс. Нужно всё, но по-разному. Но это уже тема для отдельного поста.
Не все курсы одинаково полезны
Как показала практика, большинство подобных курсов - это пустая трата денег и времени. Там вам расскажут простейшее капитанство, которое можно узнать, прочитав три статьи на хабре. Выдадут вам сертификат, который ни один работодатель не воспримет всерьез, и отправят в свободное плавание, пожелав удачи.
Причем не существует практически никакой корреляции между тем, сколько стоит курс и реальной пользой от него. Есть полезные бесплатные курсы и есть бестолковейшие курсы за >=50к
Стоит отметить, что в рамках одной площадки курсы могут тоже бесконечно варьироваться по степени своей пользы.
Как выбрать курс
В связи с пунктом выше, первое, что бы я советовал - опираться на отзывы тех, кому вы доверяете. Если толковый человек прошел курс, получил полезные знания и навыки, применил их на практике и вам похвалил - идите. Если инстаграм показал вам в перерывах между сторис рекламу курсов с красивыми словами и цифрами - стотыщ раз подумайте.
Когда уже известно, какие курсы более-менее толковые, я стараюсь выбирать по следующим критериям:
- Я не знаю тему, но она мне пригодится в обозримом будущем. Тут курс поможет въехать на начальном этапе, а дальше уже на практике, по докам, по статьям попрет самостоятельно.
- Я знаю тему по кусочкам и мне нужно структурировать все свои знания и закрыть недостающие пробелы между этими кусочками. Тут надо быть очень осторожным, ибо хороших продвинутых курсов довольно мало и найти их довольно сложно в мешанине маркетинга.
Много ли сомнительных курсов?
На мой личный взгляд - много. Большинство. Процентов 80-90.
Прошел курсы, что дальше?
Очень важно, применить полученные знания на практике. Если вы прошли технические курсы - подумайте, как вы можете с пользой для проекта применить их в своей работе (в идеале подумайте об этом ДО ТОГО, как идти на курсы). Если вы прошли менеджерские курсы - идея та же самая, сразу прикидывайте, где, что у вас болит, как будете это исправлять за счет новых знаний.
Учитесь новому, получайте пользу, берегите своё время и деньги.
Сейчас из каждого утюга вещают о том, как вас готовы научить программировать всего за N денег, и после прохождения этих чудесных курсов вы сможете зарабатывать Nx2 КАЖДЫЙ МЕСЯЦ!
Хотелось бы предупредить потенциальных жертв маркетинга, что всё немного не так, как сообщается в рекламе.
Далее последует моё личное мнение, основанное на собственном опыте (у меня его хватает) и опыте знакомых, коллег, товарищей.
Нужны ли вам курсы, чтобы "вайти в айти"?
Насколько я знаю статистику по нескольким площадкам и курсам, до конца доходит в среднем четверть. А трудоустраивается потом тоже не сильно много людей из этой четверти.
Так что если вы увидели рекламу о том, как поучитесь 2 месяца, а потом будете зарабатывать стотыщ, то прочитайте мой прошлый пост https://news.1rj.ru/str/general_it_talks/9 и крепко задумайтесь, надо ли оно вам, готовы ли вы вложить столько труда, времени и денег.
Нужны ли курсы для уже вошедших?
Я считаю, что постоянное самообразование в нашей отрасли - необходимое условие для роста и развития. Как вы это делаете, решать вам. Лично мне курсы помогают.
Тут не стоит заводить спор о том, что лучше, почитать статью на хабре, посмотреть видосик на ютубе, прочесть книгу или пройти курс. Нужно всё, но по-разному. Но это уже тема для отдельного поста.
Не все курсы одинаково полезны
Как показала практика, большинство подобных курсов - это пустая трата денег и времени. Там вам расскажут простейшее капитанство, которое можно узнать, прочитав три статьи на хабре. Выдадут вам сертификат, который ни один работодатель не воспримет всерьез, и отправят в свободное плавание, пожелав удачи.
Причем не существует практически никакой корреляции между тем, сколько стоит курс и реальной пользой от него. Есть полезные бесплатные курсы и есть бестолковейшие курсы за >=50к
Стоит отметить, что в рамках одной площадки курсы могут тоже бесконечно варьироваться по степени своей пользы.
Как выбрать курс
В связи с пунктом выше, первое, что бы я советовал - опираться на отзывы тех, кому вы доверяете. Если толковый человек прошел курс, получил полезные знания и навыки, применил их на практике и вам похвалил - идите. Если инстаграм показал вам в перерывах между сторис рекламу курсов с красивыми словами и цифрами - стотыщ раз подумайте.
Когда уже известно, какие курсы более-менее толковые, я стараюсь выбирать по следующим критериям:
- Я не знаю тему, но она мне пригодится в обозримом будущем. Тут курс поможет въехать на начальном этапе, а дальше уже на практике, по докам, по статьям попрет самостоятельно.
- Я знаю тему по кусочкам и мне нужно структурировать все свои знания и закрыть недостающие пробелы между этими кусочками. Тут надо быть очень осторожным, ибо хороших продвинутых курсов довольно мало и найти их довольно сложно в мешанине маркетинга.
Много ли сомнительных курсов?
На мой личный взгляд - много. Большинство. Процентов 80-90.
Прошел курсы, что дальше?
Очень важно, применить полученные знания на практике. Если вы прошли технические курсы - подумайте, как вы можете с пользой для проекта применить их в своей работе (в идеале подумайте об этом ДО ТОГО, как идти на курсы). Если вы прошли менеджерские курсы - идея та же самая, сразу прикидывайте, где, что у вас болит, как будете это исправлять за счет новых знаний.
Учитесь новому, получайте пользу, берегите своё время и деньги.
Telegram
Тимлид Очевидность | Евгений Антонов
Войти в айти это надолго
Сейчас из каждого утюга рассказывают о том, что в айти много зарабатывают. Онлайн курсов для начинающих появилось море, начиная от инфоцыган и заканчивая программами хороших вузов или технологических компаний.
Практически каждый…
Сейчас из каждого утюга рассказывают о том, что в айти много зарабатывают. Онлайн курсов для начинающих появилось море, начиная от инфоцыган и заканчивая программами хороших вузов или технологических компаний.
Практически каждый…
Сертификация в ИТ. Стоит ли тратить время и деньги?
В прошлом посте я высказал своё мнение про ИТ курсы, теперь логично было бы продолжить про сертификацию.
Обычно в таких спорах появляются два примерно одинаковых по численности лагеря. В одном говорят, что это бесполезная фигня: время тратишь, деньги тратишь, никто на сертификат не смотрит. В другом говорят, что это крутая штука: знаний больше, опыт больше, прибавка на текущей работе или плюс в трудоустройстве.
Раньше я находился во втором лагере. Теперь где-то в середине между ними. Кто знает, вдруг в будущем течение мысли отнесет меня в первый :)
Сертификатов я имею несколько разных. Одни давались после окончания каких-либо курсов, другие за отдельную сертификацию по той или иной технологии. Сертификаты у меня есть как бесплатные, так и платные. Максимальная сумма, которую я платил за сертификацию - 200$.
Выражу своё мнение по нескольким критериям.
Больше знаний
Если сертификация довольно серьезная и разработана ответственно, то определенную прибавку в знаниях вы скорее всего получите. Даже если вы сеньор-помидор, то всё равно, возможно, вы используете не весь арсенал данной технологии (например, не всегда хватало соответствующих задач на данный момент). Сертификация поможет закрыть пробелы и упорядочить уже имеющиеся знания.
Если сертификация была сделана по сути только для того чтобы вы заплатили деньги, а вам выдали очередную ачивку - зря потратите время и деньги.
Плюс при найме или прибавка на текущей работе
Честно говоря, я ни разу не сталкивался с тем, чтобы кому-то реально давали прибавку за то, что он сертифицировался по какой-либо технологии каким-либо самым прекрасным и респектовым в мире сертификатом. В этом плане надежд никаких не питаю и вам не советую. Однако если у вас на работе всё же за это прибавляют денег, то что же вы сидите-то? Го учиться!
Сертификат как плюс при найме - это довольно спорно. Многие смотрят на какие-то признанные в индустрии сертификаты как плюс, но по моему опыту ощутимо большее количество компаний игнорирует это дело. Лично я при найме обращаю внимание на курсы, сертификаты и прочее, однако это отнюдь не ключевое отличие, которое может сильно перевесить в ту или иную сторону. Тем не менее считаю, что если человек вкладывает своё время и деньги в курсы и сертификации по тем технологиям, с которыми работает (и смежным с ними), то он заинтересован в своём профессиональном развитии и делами демонстрирует желание учиться.
Вечный студент
Есть такая категория людей, которых затягивает достижение ачивок (в данном случае сертификатов) не ради какой-то пользы для себя и для дела, а ради самого факта ачивки. Это довольно болезненная фигня, с которой сложно слезть. У меня была такая склонность, особенно в первое время работы в индустрии. Сейчас я надеюсь, что я соскочил с этой фигни (но это не точно) и стараюсь учиться, сертифицироваться не ради дополнительного сертификатика в резюме, а ради какой-то реальной пользы в работе.
Какой сертификат получать?
Тут надо тщательно ознакомиться с информацией и фильтровать разные сертификации. При активных раскопках информации вы быстро найдете по своей технологии какую-то сертификацию, которая признана не только на этом сайте или в той компании, а прямо во всей индустрии во всём мире. Вот такую и проходите, не разменивайтесь на бесконечные левые сертификаты, на которые уж точно никто не взглянет вообще.
Итог
На мой взгляд, сертификация больше полезна, чем вредна. Особого вреда не принесет, если вы поучитесь и по определенным правилам докажете, что получили необходимые знания и навыки. Но денежки скорее всего придется потратить.
Можно ли без неё? Конечно, можно. Очень много хороших разработчиков не имеют никаких сертификатов и у них прекрасные хард скиллы и карьера. Так что это всё не обязательно и факультативно, просто смотрите как вам самим комфортно получать знания. Получайте сертификаты в перувую очередь ради знаний, а уже во вторую (или даже пятую) ради плюсика в резюме.
В прошлом посте я высказал своё мнение про ИТ курсы, теперь логично было бы продолжить про сертификацию.
Обычно в таких спорах появляются два примерно одинаковых по численности лагеря. В одном говорят, что это бесполезная фигня: время тратишь, деньги тратишь, никто на сертификат не смотрит. В другом говорят, что это крутая штука: знаний больше, опыт больше, прибавка на текущей работе или плюс в трудоустройстве.
Раньше я находился во втором лагере. Теперь где-то в середине между ними. Кто знает, вдруг в будущем течение мысли отнесет меня в первый :)
Сертификатов я имею несколько разных. Одни давались после окончания каких-либо курсов, другие за отдельную сертификацию по той или иной технологии. Сертификаты у меня есть как бесплатные, так и платные. Максимальная сумма, которую я платил за сертификацию - 200$.
Выражу своё мнение по нескольким критериям.
Больше знаний
Если сертификация довольно серьезная и разработана ответственно, то определенную прибавку в знаниях вы скорее всего получите. Даже если вы сеньор-помидор, то всё равно, возможно, вы используете не весь арсенал данной технологии (например, не всегда хватало соответствующих задач на данный момент). Сертификация поможет закрыть пробелы и упорядочить уже имеющиеся знания.
Если сертификация была сделана по сути только для того чтобы вы заплатили деньги, а вам выдали очередную ачивку - зря потратите время и деньги.
Плюс при найме или прибавка на текущей работе
Честно говоря, я ни разу не сталкивался с тем, чтобы кому-то реально давали прибавку за то, что он сертифицировался по какой-либо технологии каким-либо самым прекрасным и респектовым в мире сертификатом. В этом плане надежд никаких не питаю и вам не советую. Однако если у вас на работе всё же за это прибавляют денег, то что же вы сидите-то? Го учиться!
Сертификат как плюс при найме - это довольно спорно. Многие смотрят на какие-то признанные в индустрии сертификаты как плюс, но по моему опыту ощутимо большее количество компаний игнорирует это дело. Лично я при найме обращаю внимание на курсы, сертификаты и прочее, однако это отнюдь не ключевое отличие, которое может сильно перевесить в ту или иную сторону. Тем не менее считаю, что если человек вкладывает своё время и деньги в курсы и сертификации по тем технологиям, с которыми работает (и смежным с ними), то он заинтересован в своём профессиональном развитии и делами демонстрирует желание учиться.
Вечный студент
Есть такая категория людей, которых затягивает достижение ачивок (в данном случае сертификатов) не ради какой-то пользы для себя и для дела, а ради самого факта ачивки. Это довольно болезненная фигня, с которой сложно слезть. У меня была такая склонность, особенно в первое время работы в индустрии. Сейчас я надеюсь, что я соскочил с этой фигни (но это не точно) и стараюсь учиться, сертифицироваться не ради дополнительного сертификатика в резюме, а ради какой-то реальной пользы в работе.
Какой сертификат получать?
Тут надо тщательно ознакомиться с информацией и фильтровать разные сертификации. При активных раскопках информации вы быстро найдете по своей технологии какую-то сертификацию, которая признана не только на этом сайте или в той компании, а прямо во всей индустрии во всём мире. Вот такую и проходите, не разменивайтесь на бесконечные левые сертификаты, на которые уж точно никто не взглянет вообще.
Итог
На мой взгляд, сертификация больше полезна, чем вредна. Особого вреда не принесет, если вы поучитесь и по определенным правилам докажете, что получили необходимые знания и навыки. Но денежки скорее всего придется потратить.
Можно ли без неё? Конечно, можно. Очень много хороших разработчиков не имеют никаких сертификатов и у них прекрасные хард скиллы и карьера. Так что это всё не обязательно и факультативно, просто смотрите как вам самим комфортно получать знания. Получайте сертификаты в перувую очередь ради знаний, а уже во вторую (или даже пятую) ради плюсика в резюме.
Тимлид. Круто? Гемор? Всё сразу
Недавно в чате подкаста "Цинковый прод" (заходите, общайтесь https://news.1rj.ru/str/ZnProd) имел разговор про тимлидство. Круто это или не круто, сколько гемора и сколько радости приносит. Поговорил там, а подведу итог в одном посте тут:) Буду описывать это на своём опыте.
Буду рассматривать только вариант перехода из разработчиков в тимлиды, т.к. не имел детального общения с менеджерами, которые из словоблудия переквалифицировались в тимлидство технической команды. Хотя, конечно, слышал о таких вариантах, когда тимлид - это такой менеджер команды, который вовремя похвалит, когда надо чаю нальет и пиццу закажет, время от времени жилетку под слезу подставит. Не исключаю, что в каких-то командах это вполне рабочий вариант.
Моя же ситуация - это "играющий тренер". Когда ты наполовину уже менеджер, а наполовину разработчик, и стараешься поддерживать порядок как в рабочих процессах, так и в разработке приложения.
Вообще нет однозначного ответа хорошо ли или плохо быть тимлидом, поэтому я рассмотрю плюсы и минусы, с которыми столкнулся я, а вы уж там сами для себя решайте.
Минусы:
Больше ответственности
Когда ты рядовой разработчик - ты несешь ответственность только за свой код (да честно говоря и то не всегда). Когда ты тимлид - с тебя спрос за всё, что сделала твоя команда. И не только как она написала код, а как это отражается на бизнес показателях. Приходится переключать мышление от "Ну вот этот код смотрится красивее. Вчера на конфе услыхал про технологию N - надо всё переписать" на "ДЕНЬГИ! СРОКИ! ЗАКАЗЧИКИ! ПОДДЕРЖКА! ЛЮДИ!".
Иными словами, всё как в армии. Рядовой опиз**ляется за себя, а сержант за весь взвод.
Больше работы, больше тоски
В моем варианте "играющего тренера" надо уделять время и процессам, и команде, и заказчикам. Однако код писать тоже надо. Тут появляется неприятное чувство, когда весь день у тебя встречи, планерки, письма, обсуждения, а к вечеру кажется, что раз код не написал, то будто ничего и не сделал. Садишься в мыле писать код, час-два пописал, день кончился, и ты думаешь: "блин, да как так мало-то?".
На этом этапе многие технари сильно приунывают, и некоторые с облегчением идут обратно в разработку.
Больше работы с людьми
Я думаю, тут не надо объяснять, что когда ты пишешь код, он работает достаточно предсказуемо, понятно и покладисто. Когда ты работаешь с людьми - это невероятный рандом и тут нужно запастись хрустальным шаром, валерьянкой и большим запасом терпения. Вот вам классическая картинка про это https://cs4.pikabu.ru/post_img/big/2015/06/22/9/1434981752_1194744087.jpg
Страх, что на рынке труда ты стремительно летишь в пропасть
Появляется определенный страх, что когда ты хороший технический специалист, ты таким же технарем с такой же примерно ценностью будешь и в любой другой команде. А когда ты тимлид-полуменеждер, то как технарь ты стагнируешь, а как менеджер ты развиваешься в конкретной компании. А в других компаниях есть уже свои менеджеры, которые всех знают и в возне под корпоративным ковром чувствуют себя как дома.
Страх, что назад дороги нет
См. предыдущий пункт. Страх, что ты не просто летишь в пропасть, а что из неё уже не сможешь выбраться.
Недавно в чате подкаста "Цинковый прод" (заходите, общайтесь https://news.1rj.ru/str/ZnProd) имел разговор про тимлидство. Круто это или не круто, сколько гемора и сколько радости приносит. Поговорил там, а подведу итог в одном посте тут:) Буду описывать это на своём опыте.
Буду рассматривать только вариант перехода из разработчиков в тимлиды, т.к. не имел детального общения с менеджерами, которые из словоблудия переквалифицировались в тимлидство технической команды. Хотя, конечно, слышал о таких вариантах, когда тимлид - это такой менеджер команды, который вовремя похвалит, когда надо чаю нальет и пиццу закажет, время от времени жилетку под слезу подставит. Не исключаю, что в каких-то командах это вполне рабочий вариант.
Моя же ситуация - это "играющий тренер". Когда ты наполовину уже менеджер, а наполовину разработчик, и стараешься поддерживать порядок как в рабочих процессах, так и в разработке приложения.
Вообще нет однозначного ответа хорошо ли или плохо быть тимлидом, поэтому я рассмотрю плюсы и минусы, с которыми столкнулся я, а вы уж там сами для себя решайте.
Минусы:
Больше ответственности
Когда ты рядовой разработчик - ты несешь ответственность только за свой код (да честно говоря и то не всегда). Когда ты тимлид - с тебя спрос за всё, что сделала твоя команда. И не только как она написала код, а как это отражается на бизнес показателях. Приходится переключать мышление от "Ну вот этот код смотрится красивее. Вчера на конфе услыхал про технологию N - надо всё переписать" на "ДЕНЬГИ! СРОКИ! ЗАКАЗЧИКИ! ПОДДЕРЖКА! ЛЮДИ!".
Иными словами, всё как в армии. Рядовой опиз**ляется за себя, а сержант за весь взвод.
Больше работы, больше тоски
В моем варианте "играющего тренера" надо уделять время и процессам, и команде, и заказчикам. Однако код писать тоже надо. Тут появляется неприятное чувство, когда весь день у тебя встречи, планерки, письма, обсуждения, а к вечеру кажется, что раз код не написал, то будто ничего и не сделал. Садишься в мыле писать код, час-два пописал, день кончился, и ты думаешь: "блин, да как так мало-то?".
На этом этапе многие технари сильно приунывают, и некоторые с облегчением идут обратно в разработку.
Больше работы с людьми
Я думаю, тут не надо объяснять, что когда ты пишешь код, он работает достаточно предсказуемо, понятно и покладисто. Когда ты работаешь с людьми - это невероятный рандом и тут нужно запастись хрустальным шаром, валерьянкой и большим запасом терпения. Вот вам классическая картинка про это https://cs4.pikabu.ru/post_img/big/2015/06/22/9/1434981752_1194744087.jpg
Страх, что на рынке труда ты стремительно летишь в пропасть
Появляется определенный страх, что когда ты хороший технический специалист, ты таким же технарем с такой же примерно ценностью будешь и в любой другой команде. А когда ты тимлид-полуменеждер, то как технарь ты стагнируешь, а как менеджер ты развиваешься в конкретной компании. А в других компаниях есть уже свои менеджеры, которые всех знают и в возне под корпоративным ковром чувствуют себя как дома.
Страх, что назад дороги нет
См. предыдущий пункт. Страх, что ты не просто летишь в пропасть, а что из неё уже не сможешь выбраться.
Плюсы
Больше возможностей на что-то повлиять
Наверное, этот пункт оказался для меня самым важным. В целом у меня не было никогда тщеславного стремления "Вот буду тимлидом и буду самым крутым. Все меня будут любить и уважать". Просто я никогда не мог стоять в стороне, когда что-то идет не так, что-то можно изменить, но почему-то никто этого не делает. Я никогда не боялся, да и не понимал почему тут вообще надо бояться, проявлять инициативу, предлагать, делать, нести ответственность за свои предложения. И как-то так органически оказывается, что меня продвигают в лидские позиции.
Тут всё зависит от склада характера и лично для меня этот пункт в плюсе. Хотя я работал с многими отличнейшими специалистами, кому это не надо было и ничего предосудительного в этом не вижу.
Больше денег
Ну да, больше ответственности, больше работы = больше денег. Но тут измеряйте сами. Видел случаи, где накидывали 10-20к денег, а работы и ответственности столько, что человек очень сильно приунывал.
Хотя этот плюс, конечно, спорный. Хорошие технари получают порой не меньше тимлидов, да и в одной компании на вас могут накинуть стопицот обязанностей и платить N, а вы идете в другую компанию, где надо просто нормально таски закрывать и код писать, а заплатят вам там > N.
Твердые позиции на рынке труда
Этот пункт я добавил для утешения самого себя. Думаю, что этот страх надуманный и, если вы адекватный тимлид с нормальным (даже не отличным) техническим бэкграундом, вам будут рады много где. Этот пункт подкрепляется как регулярными предложениями мне с рынка труда (хотя сейчас эти предложения делают всем, кто своё имя пишет без ошибок и под себя не ходит), так и моим опытом работы с другими командами и компаниями. Реально очень сложно найти на той стороне такую точку входа в команду, с которой было бы просто, понятно и предсказуемо работать. А если нашел, то капец как это ценишь и реально получаешь удовольствие от работы с такими людьми.
Не отнесу ни к плюсам, ни к минусам пункт Найм
С одной стороны, поиск кандидатов, подготовка тестовых заданий, собеседования - это гемор. А с другой стороны - реальный шанс повлиять на то, с кем тебе и твоей команде предстоит работать.
Итог
Каждый должен хорошенечко подумать и посмотреть на свой характер и то, к чему душа лежит. Не гонитесь за деньгами и уж тем более за абстрактной "властью" (которой по большому счету у тимлида и нет практически). Делайте то, что вам действительно хочется делать (благо пока индустрия позволяет нам быть настолько избирательными) и сами придете к правильным карьерным позициям.
Больше возможностей на что-то повлиять
Наверное, этот пункт оказался для меня самым важным. В целом у меня не было никогда тщеславного стремления "Вот буду тимлидом и буду самым крутым. Все меня будут любить и уважать". Просто я никогда не мог стоять в стороне, когда что-то идет не так, что-то можно изменить, но почему-то никто этого не делает. Я никогда не боялся, да и не понимал почему тут вообще надо бояться, проявлять инициативу, предлагать, делать, нести ответственность за свои предложения. И как-то так органически оказывается, что меня продвигают в лидские позиции.
Тут всё зависит от склада характера и лично для меня этот пункт в плюсе. Хотя я работал с многими отличнейшими специалистами, кому это не надо было и ничего предосудительного в этом не вижу.
Больше денег
Ну да, больше ответственности, больше работы = больше денег. Но тут измеряйте сами. Видел случаи, где накидывали 10-20к денег, а работы и ответственности столько, что человек очень сильно приунывал.
Хотя этот плюс, конечно, спорный. Хорошие технари получают порой не меньше тимлидов, да и в одной компании на вас могут накинуть стопицот обязанностей и платить N, а вы идете в другую компанию, где надо просто нормально таски закрывать и код писать, а заплатят вам там > N.
Твердые позиции на рынке труда
Этот пункт я добавил для утешения самого себя. Думаю, что этот страх надуманный и, если вы адекватный тимлид с нормальным (даже не отличным) техническим бэкграундом, вам будут рады много где. Этот пункт подкрепляется как регулярными предложениями мне с рынка труда (хотя сейчас эти предложения делают всем, кто своё имя пишет без ошибок и под себя не ходит), так и моим опытом работы с другими командами и компаниями. Реально очень сложно найти на той стороне такую точку входа в команду, с которой было бы просто, понятно и предсказуемо работать. А если нашел, то капец как это ценишь и реально получаешь удовольствие от работы с такими людьми.
Не отнесу ни к плюсам, ни к минусам пункт Найм
С одной стороны, поиск кандидатов, подготовка тестовых заданий, собеседования - это гемор. А с другой стороны - реальный шанс повлиять на то, с кем тебе и твоей команде предстоит работать.
Итог
Каждый должен хорошенечко подумать и посмотреть на свой характер и то, к чему душа лежит. Не гонитесь за деньгами и уж тем более за абстрактной "властью" (которой по большому счету у тимлида и нет практически). Делайте то, что вам действительно хочется делать (благо пока индустрия позволяет нам быть настолько избирательными) и сами придете к правильным карьерным позициям.
Стоит ли принимать контроффер?
В середине января на хабре вышла статья от Жени Остроумовой о том, что контроффер лучше не принимать. Ссылка https://habr.com/ru/company/dodopizzadev/blog/483794/
В целом с материалом я согласен, но считаю, что требуется одно важное уточнение, которое наполовину опровергает главный тезис статьи.
Уточнить требуется то, откуда у вас этот контроффер вообще появился. В ИТ в большинстве случаев два варианта:
Вариант №1
Вы находитесь в активном поиске, потому что заколебала текущая работу/хочется ощутимо больше денег, а здесь столько не прибавят/хочется расти, а тут роста нет. Тогда вы идете на рынок труда с твердым пониманием того, что на текущем месте работы вам дискомфортно, собеседуетесь, получаете оффер, приходите увольняться, получаете контроффер. В этом случае я согласен с Женей. Лучше уходить, потому что раз уж вы решили, что вам тут дискомфортно, то сиюминутная прибавка этот дискомфорт снимет лишь кратковременно. Вскоре вы опять начнете грустить, тосковать, открывать резюме.
Стоит отметить, что прежде, чем вы приметесь за решительные шаги, убедитесь, что всё действительно плохо, а не просто вы сами себе придумали, сами обиделись. Это долгая тема для отдельного поста :)
Вариант №2
Вы не находитесь в активном поиске. Вас в текущей работе всё устраивает. Но в ИТ, как мы все знаем, даже если ты не ищешь работу, к тебе приходят много рекрутеров и предлагают свои варианты. И вот в солнечный летний день вам приносят вакансию вполне любопытную: и платят больше, и в целом впечатление позитивное от общения. Перед вами встает моральная дилемма о том, что и тут хорошо, и там неплохо, даже выгоднее. Если вы действительно хороший работник, приносите много пользы на своем месте и вам правда вполне хорошо работается на текущей работе, то тут вам руководство может сделать контроффер, чтобы вас удержать. Я не вижу ничего плохого чтобы его принять. В отличие от первого варианта, в будущем вы будете чувствовать себя не хуже со временем, а только лучше, понимая, что вас тут ценят, любят, удерживают, создают хорошие условия. А работодатель - да, потратится конечно, но если работник и правда ценный, то окупит это лояльностью сотрудника и тем, что тот просидит на своем месте еще долго, а значит не придется тратиться больше на его замену. Надо не забывать, что заменить сотрудника (особенно если это не рядовой сотрудник, а лид, тимлид и выше) даже на ту же самую зарплату - это очень дорого. Дороже и рискованнее, чем дать разумную прибавку текущему работнику.
Отдельным пунктом стоит проблема "вот вы сходите на рынок труда, получите оффер, вам выдадут контроффер, но потом будут на вас косо смотреть". Ну да, такое вполне может быть где-то в сомнительных региональных компаниях, в другой сфере труда, или просто потому, что вы такой мудак, который вместо того, чтобы делать свою работу, ходит по собеседованиям каждый месяц и деньги клянчит.
А если вы хорошо и добросовестно делаете свою работу, то переживать не стоит. Nothing personal just business. Вы отдаете компании свой труд, время, приносите ей прибыль, а она платит вам деньги. Тут практически никогда нет персональных отношений (даже когда это вроде бы заявляется). И уж поверьте, если бы компания нашла сотрудника, который мог бы вас в одночасье эквивалентно заменить за ощутимо меньшую зарплату, то вас бы или заменили сразу, или пришли к вам, чтобы уже вы делали контроффер на понижение своей зарплаты.
P.S. Если у вас в компании наблюдается острая реакция даже на незначительный намек, что кто-то открыл сайт hh или ответит рекрутеру в Linkedin, или сходил на конференцию где РЕКРУТЕРЫ НА КАЖДОМ СТЕНДЕ, или "МЫ ЖЕ ДЛЯ ТЕБЯ СТОЛЬКО СДЕЛАЛИ, ТЫ ДОЛЖЕН БЫТЬ АБСОЛЮТНО ЛОЯЛЕН И ПОДДЕРЖИВАТЬ ИДЕАЛЫ КОМПАНИИ, ДА КАК ТЫ ВООБЩЕ МОЖЕШЬ??!!", то задумайтесь, почему так происходит. Спойлерить не буду, это такое легкое факультативное задание. Даже без звездочки.
В середине января на хабре вышла статья от Жени Остроумовой о том, что контроффер лучше не принимать. Ссылка https://habr.com/ru/company/dodopizzadev/blog/483794/
В целом с материалом я согласен, но считаю, что требуется одно важное уточнение, которое наполовину опровергает главный тезис статьи.
Уточнить требуется то, откуда у вас этот контроффер вообще появился. В ИТ в большинстве случаев два варианта:
Вариант №1
Вы находитесь в активном поиске, потому что заколебала текущая работу/хочется ощутимо больше денег, а здесь столько не прибавят/хочется расти, а тут роста нет. Тогда вы идете на рынок труда с твердым пониманием того, что на текущем месте работы вам дискомфортно, собеседуетесь, получаете оффер, приходите увольняться, получаете контроффер. В этом случае я согласен с Женей. Лучше уходить, потому что раз уж вы решили, что вам тут дискомфортно, то сиюминутная прибавка этот дискомфорт снимет лишь кратковременно. Вскоре вы опять начнете грустить, тосковать, открывать резюме.
Стоит отметить, что прежде, чем вы приметесь за решительные шаги, убедитесь, что всё действительно плохо, а не просто вы сами себе придумали, сами обиделись. Это долгая тема для отдельного поста :)
Вариант №2
Вы не находитесь в активном поиске. Вас в текущей работе всё устраивает. Но в ИТ, как мы все знаем, даже если ты не ищешь работу, к тебе приходят много рекрутеров и предлагают свои варианты. И вот в солнечный летний день вам приносят вакансию вполне любопытную: и платят больше, и в целом впечатление позитивное от общения. Перед вами встает моральная дилемма о том, что и тут хорошо, и там неплохо, даже выгоднее. Если вы действительно хороший работник, приносите много пользы на своем месте и вам правда вполне хорошо работается на текущей работе, то тут вам руководство может сделать контроффер, чтобы вас удержать. Я не вижу ничего плохого чтобы его принять. В отличие от первого варианта, в будущем вы будете чувствовать себя не хуже со временем, а только лучше, понимая, что вас тут ценят, любят, удерживают, создают хорошие условия. А работодатель - да, потратится конечно, но если работник и правда ценный, то окупит это лояльностью сотрудника и тем, что тот просидит на своем месте еще долго, а значит не придется тратиться больше на его замену. Надо не забывать, что заменить сотрудника (особенно если это не рядовой сотрудник, а лид, тимлид и выше) даже на ту же самую зарплату - это очень дорого. Дороже и рискованнее, чем дать разумную прибавку текущему работнику.
Отдельным пунктом стоит проблема "вот вы сходите на рынок труда, получите оффер, вам выдадут контроффер, но потом будут на вас косо смотреть". Ну да, такое вполне может быть где-то в сомнительных региональных компаниях, в другой сфере труда, или просто потому, что вы такой мудак, который вместо того, чтобы делать свою работу, ходит по собеседованиям каждый месяц и деньги клянчит.
А если вы хорошо и добросовестно делаете свою работу, то переживать не стоит. Nothing personal just business. Вы отдаете компании свой труд, время, приносите ей прибыль, а она платит вам деньги. Тут практически никогда нет персональных отношений (даже когда это вроде бы заявляется). И уж поверьте, если бы компания нашла сотрудника, который мог бы вас в одночасье эквивалентно заменить за ощутимо меньшую зарплату, то вас бы или заменили сразу, или пришли к вам, чтобы уже вы делали контроффер на понижение своей зарплаты.
P.S. Если у вас в компании наблюдается острая реакция даже на незначительный намек, что кто-то открыл сайт hh или ответит рекрутеру в Linkedin, или сходил на конференцию где РЕКРУТЕРЫ НА КАЖДОМ СТЕНДЕ, или "МЫ ЖЕ ДЛЯ ТЕБЯ СТОЛЬКО СДЕЛАЛИ, ТЫ ДОЛЖЕН БЫТЬ АБСОЛЮТНО ЛОЯЛЕН И ПОДДЕРЖИВАТЬ ИДЕАЛЫ КОМПАНИИ, ДА КАК ТЫ ВООБЩЕ МОЖЕШЬ??!!", то задумайтесь, почему так происходит. Спойлерить не буду, это такое легкое факультативное задание. Даже без звездочки.
Хабр
Уходя уходи: почему не стоит принимать контроффер
Привет, Хабр! Меня зовут Женя Остроумова, и я рекрутёр_ка. Сегодня поговорим с вами про контрофферы. Серия статей про собеседования : 1. Наш первый обед вместе: почему и как мы проводим тестовый день...
Итог
Трудитесь хорошо и добросовестно. Помните, что мы зарабатываем много денег, покуда приносим своей компании еще больше. Не стесняйтесь отстаивать свои интересы. Лояльностью и одобряющими похлопываниями по плечу на тимбилдинге ипотеку вы не выплатите и семью не накормите.
Трудитесь хорошо и добросовестно. Помните, что мы зарабатываем много денег, покуда приносим своей компании еще больше. Не стесняйтесь отстаивать свои интересы. Лояльностью и одобряющими похлопываниями по плечу на тимбилдинге ипотеку вы не выплатите и семью не накормите.
Я получил задачу. Что дальше?
Рассмотрю несколько вариантов развития событий, основываясь на своем опыте и опыте коллег из других компаний.
Сразу стоит отметить, что у меня нет для вас релевантного опыта проектов, на которых очень много людей (30-50-100+) работает. Есть только опыт для команд из 5-10-15-20 человек.
Вариант №1
Программист, получивший задание, смиряется с рядом надежд (они же риски):
- ТЗ написано внятно, корректно, без противоречий.
- Заказчик точно уверен, что ему это вообще нужно и именно так, как он просит.
- ПМ/тимлид/старший товарищ эту задачу обдумали, обсудили, разжевали и только после этого передали ему.
Ну и всё, программист особо не заморачивается, делает задачу в надежде, что риски не стрельнут. Иначе ему придется или что-то переделывать (порой много чего) или вообще его поделка не увидит свет.
Как показывает практика, эти риски стреляют довольно часто в силу разных причин: плохо договорились, не подумали, поговорили на разных языках (образно), каждый понадеялся на другого и т.д.
Вариант №2
Программист, получивший задание, старается устранить эти риски. Лично я делаю так и рекомендую так же поступать коллегам на всех этапах работы, начиная от начального этапа сбора требований.
Следует понимать, что заказчик порой сам не уверен, что ему нужно конкретно вот так вот сделать. Однако приходит он к вам с уверенным лицом. Вам надо помочь ему понять, действительно ли ему это надо, действительно ли вот так, а не иначе, что он хочет от этого получить и т.д. Помогите ему разобраться, помогите доработать ТЗ, помогите себе и вашим коллегам обрести уверенность в том, что эту задачу не надо будет переделывать или отменять.
Да, вы потратите несколько больше времени на этапе выявления требований и проектирования, но в дальнейшем сэкономите время и нервы, плюс сможете получать более предсказуемый и прогнозируемый результат своей работы.
Нихотю
Вы справедливо можете сказать: "А что это я буду с этим разбираться? Вон ПМ есть, тимлид, лид. Пусть они и разбираются. Мне деньги платят, чтобы я код писал». Ну да, всё так и есть. Вы совершенно правы, и, конечно, никто вас принудить к этому не может, если вы не хотите. Но помните, что потому тимлид/лид и заняли свои позиции, что не брезговали погружаться не только в код, но и в бизнес часть проекта. Желаю вам удачи на очередных торгах за повышение зарплаты:)
Итог
Важно и нужно анализировать задачи, начиная с самых ранних этапов. Не надо быть наивным в надежде на то, что ничего не случится, и до вас все подумали хорошо, потому что они специалисты (не факт).
Тот, кто этим займется - будет ощутимо ценнее для бизнеса и команды, чем тот "с чьей стороны пули вылетели". Успехов!
Рассмотрю несколько вариантов развития событий, основываясь на своем опыте и опыте коллег из других компаний.
Сразу стоит отметить, что у меня нет для вас релевантного опыта проектов, на которых очень много людей (30-50-100+) работает. Есть только опыт для команд из 5-10-15-20 человек.
Вариант №1
Программист, получивший задание, смиряется с рядом надежд (они же риски):
- ТЗ написано внятно, корректно, без противоречий.
- Заказчик точно уверен, что ему это вообще нужно и именно так, как он просит.
- ПМ/тимлид/старший товарищ эту задачу обдумали, обсудили, разжевали и только после этого передали ему.
Ну и всё, программист особо не заморачивается, делает задачу в надежде, что риски не стрельнут. Иначе ему придется или что-то переделывать (порой много чего) или вообще его поделка не увидит свет.
Как показывает практика, эти риски стреляют довольно часто в силу разных причин: плохо договорились, не подумали, поговорили на разных языках (образно), каждый понадеялся на другого и т.д.
Вариант №2
Программист, получивший задание, старается устранить эти риски. Лично я делаю так и рекомендую так же поступать коллегам на всех этапах работы, начиная от начального этапа сбора требований.
Следует понимать, что заказчик порой сам не уверен, что ему нужно конкретно вот так вот сделать. Однако приходит он к вам с уверенным лицом. Вам надо помочь ему понять, действительно ли ему это надо, действительно ли вот так, а не иначе, что он хочет от этого получить и т.д. Помогите ему разобраться, помогите доработать ТЗ, помогите себе и вашим коллегам обрести уверенность в том, что эту задачу не надо будет переделывать или отменять.
Да, вы потратите несколько больше времени на этапе выявления требований и проектирования, но в дальнейшем сэкономите время и нервы, плюс сможете получать более предсказуемый и прогнозируемый результат своей работы.
Нихотю
Вы справедливо можете сказать: "А что это я буду с этим разбираться? Вон ПМ есть, тимлид, лид. Пусть они и разбираются. Мне деньги платят, чтобы я код писал». Ну да, всё так и есть. Вы совершенно правы, и, конечно, никто вас принудить к этому не может, если вы не хотите. Но помните, что потому тимлид/лид и заняли свои позиции, что не брезговали погружаться не только в код, но и в бизнес часть проекта. Желаю вам удачи на очередных торгах за повышение зарплаты:)
Итог
Важно и нужно анализировать задачи, начиная с самых ранних этапов. Не надо быть наивным в надежде на то, что ничего не случится, и до вас все подумали хорошо, потому что они специалисты (не факт).
Тот, кто этим займется - будет ощутимо ценнее для бизнеса и команды, чем тот "с чьей стороны пули вылетели". Успехов!
Пришло время анонсировать свои скромные услуги по консалтингу. Всё написано тут https://antonov-dev.ru/consulting
Так что обращайтесь, если у кого какие-то проблемы и хочется лично обсудить, проработать, подыскать варианты решения.
Это не отменяет регулярных пятничных постов, всё продолжится по расписанию :)
Так что обращайтесь, если у кого какие-то проблемы и хочется лично обсудить, проработать, подыскать варианты решения.
Это не отменяет регулярных пятничных постов, всё продолжится по расписанию :)
antonov-dev.ru
ИТ консультации
Евгений Антонов. ИТ консультации
👍2🔥2
Тимлид Очевидность | Евгений Антонов pinned «Пришло время анонсировать свои скромные услуги по консалтингу. Всё написано тут https://antonov-dev.ru/consulting Так что обращайтесь, если у кого какие-то проблемы и хочется лично обсудить, проработать, подыскать варианты решения. Это не отменяет регулярных…»
Пара лайфхаков про письменное общение
Сейчас многие перешли на удаленную работу (на работу в распределенной команде, если вам так приятнее) и всё чаще начинают всплывать проблемы из-за недостаточной культуры письма. Проблем много, но в сегодняшнем посте я хотел бы описать две довольно частые. Может быть на следующей неделе вернемся к остальным, посмотрю по статистике инцидентов :)
Излишне частые короткие сообщения
В вашем уютном чатике сидит примерно десяток людей из вашей команды. Каждый раз они получают уведомления, когда кто-то что-то в него написал. Это отвлекает. Если вы каждое предложение отправляете отдельным сообщением (а некоторые даже умудряются одно предложение уместить в 2-3 сообщения), то вы отвлекаете всех этих людей очень часто без необходимости. И мало того, что вы постоянно дергаете людей, заколебывая оповещениями, так вы еще заставляете людей не просто посмотреть, что там за сообщение, а сидеть ждать, пока вы там допишите наконец свою тираду. Ведь они пришли уже в начале или середине мысли, значит, скорее всего будут ждать до конца, и есть все шансы, что будут разочарованы. Особенно интересно смотрится, когда после пяти сообщений идет «ааааа, не, я понял(а), это не так надо, а по-другому». Этакий групповой сеанс с коллегами в роли резиновых уточек. Не надо так.
Если вам настолько нужно поделиться своей щедрой, широкой мыслью, напишите осмысленный абзац текста, выделите, при необходимости, ключевые мысли или слова жирным шрифтом, или еще как-нибудь явно. Это поможет вам же самим обдумать и сформулировать правильно и понятно свои мысли и потребности. Поверьте, это не сложно, если перестать лениться и начать хорошенько думать, прежде чем выливать на коллег потоки информации (словесного поноса).
Непонятная формулировка. Хрустальный шар сломался
Когда формулируете своим коллегам какую-то просьбу или задачу в попытке донести до них важные мысли, постарайтесь исходить из предположения, что контекст этой проблемы им неизвестен совсем или известен, но плохо, и они его забыли (а так скорее всего и есть).
Не надейтесь, что у всех работают хрустальные шары, с помощью которых они смогут отгадать ваши потаенные мысли, что люди абсолютно точно понимают ваши специфические термины, что люди знают какие-то особенности вашего проекта, того, с кем вы работаете или вашего личного графика.
Просто и явно поясните все предпосылки задачи: какие проблемы, какие цели, какие предполагаемые решения, какие сроки, кто контактные лица, какие-то еще особенности.
Чем подробнее вы опишите, тем быстрее задача будет сделана. Вы меньше потратите своего и чужого времени на обсуждение, уточнение и ненужные диалоги, которых можно было бы избежать. Ну и при понятной формулировке ниже шанс, что придется задачу переделывать, потому что коллега не смог выйти в астрал и неправильно угадал, что же вы на самом деле хотели и зачем.
Итог
В распределенных командах очень важна культура письменных коммуникаций. Взращивайте её в команде и эффективность вашей работы повысится, а уровень ярости в чатиках снизится. Уважайте время и труд своих коллег.
Сейчас многие перешли на удаленную работу (на работу в распределенной команде, если вам так приятнее) и всё чаще начинают всплывать проблемы из-за недостаточной культуры письма. Проблем много, но в сегодняшнем посте я хотел бы описать две довольно частые. Может быть на следующей неделе вернемся к остальным, посмотрю по статистике инцидентов :)
Излишне частые короткие сообщения
В вашем уютном чатике сидит примерно десяток людей из вашей команды. Каждый раз они получают уведомления, когда кто-то что-то в него написал. Это отвлекает. Если вы каждое предложение отправляете отдельным сообщением (а некоторые даже умудряются одно предложение уместить в 2-3 сообщения), то вы отвлекаете всех этих людей очень часто без необходимости. И мало того, что вы постоянно дергаете людей, заколебывая оповещениями, так вы еще заставляете людей не просто посмотреть, что там за сообщение, а сидеть ждать, пока вы там допишите наконец свою тираду. Ведь они пришли уже в начале или середине мысли, значит, скорее всего будут ждать до конца, и есть все шансы, что будут разочарованы. Особенно интересно смотрится, когда после пяти сообщений идет «ааааа, не, я понял(а), это не так надо, а по-другому». Этакий групповой сеанс с коллегами в роли резиновых уточек. Не надо так.
Если вам настолько нужно поделиться своей щедрой, широкой мыслью, напишите осмысленный абзац текста, выделите, при необходимости, ключевые мысли или слова жирным шрифтом, или еще как-нибудь явно. Это поможет вам же самим обдумать и сформулировать правильно и понятно свои мысли и потребности. Поверьте, это не сложно, если перестать лениться и начать хорошенько думать, прежде чем выливать на коллег потоки информации (словесного поноса).
Непонятная формулировка. Хрустальный шар сломался
Когда формулируете своим коллегам какую-то просьбу или задачу в попытке донести до них важные мысли, постарайтесь исходить из предположения, что контекст этой проблемы им неизвестен совсем или известен, но плохо, и они его забыли (а так скорее всего и есть).
Не надейтесь, что у всех работают хрустальные шары, с помощью которых они смогут отгадать ваши потаенные мысли, что люди абсолютно точно понимают ваши специфические термины, что люди знают какие-то особенности вашего проекта, того, с кем вы работаете или вашего личного графика.
Просто и явно поясните все предпосылки задачи: какие проблемы, какие цели, какие предполагаемые решения, какие сроки, кто контактные лица, какие-то еще особенности.
Чем подробнее вы опишите, тем быстрее задача будет сделана. Вы меньше потратите своего и чужого времени на обсуждение, уточнение и ненужные диалоги, которых можно было бы избежать. Ну и при понятной формулировке ниже шанс, что придется задачу переделывать, потому что коллега не смог выйти в астрал и неправильно угадал, что же вы на самом деле хотели и зачем.
Итог
В распределенных командах очень важна культура письменных коммуникаций. Взращивайте её в команде и эффективность вашей работы повысится, а уровень ярости в чатиках снизится. Уважайте время и труд своих коллег.
👍2❤1
Герои хаоса, тушители саморазожженных пожаров
Fake Heroes
Наверное, у вас есть коллеги, которые постоянно вращаются в водовороте хаоса и проблем на работе. С видом героев они тушат множественные пожары по всем фронтам и предотвращают катастрофу в последний момент.
Возможно, вы даже смотрите на них и говорите: «Ах, как(ой/ая) молодец! Ведь столько дел, а всё успевает, везде помогает. Овертаймит постоянно, по вечерам, ночам, выходным. Сколько сил и самоотверженности у человека!».
Если вдруг вы из тех, кто по наивности так думает, то рекомендую вам немножко внимательнее вглядеться в работу этих людей. Не слушайте, как они трубят о том, что сегодня потушили три пожара, а вчера победили вселенскую энтропию. Смотрите на то, кто зажигал эти пожары и откуда пошла энтропия. Результат вас может сильно удивить.
Окажется, что во многих случаях герои сами и разжигают пожары, которые затем победоносно тушат. Разжигают не то что прям со зла, а скорее своей неорганизованностью, безответственностью и несистемным подходом к задачам. У таких людей все сроки закончились вчера, ТЗ только на словах, а ответов на вопросы не дождешься, ибо они уже на другой пожар умчались. Это не потому, что они в какой-то такой особенной вселенной живут, или какая-то сфера деятельности настолько специфичная. А потому что такой вот подход к организации своей работы, а заодно и тех, кто от нее зависит.
True Heroes
Для разнообразия попробуйте поискать среди своих коллег других героев невидимого фронта. Они не слагают славных песен о своих подвигах. Они не уходят с работы глубокой ночью. Они не пишут вам письма на выходных. Они всегда вас предупреждают заранее. Они планируют свою работу и согласовывают её с вами. Они всегда вам готовы ответить на ваши вопросы. Они просто делают всё вовремя и уходят домой (в закат). На мой взгляд, именно они – настоящие герои в работе.
Итог
Прекратите поощрять разжигателей пожаров. Думайте над своей работой, над рабочими процессами, не пускайте всё на самотек, уважайте чужое время и труд. Будьте настоящими героями!
Fake Heroes
Наверное, у вас есть коллеги, которые постоянно вращаются в водовороте хаоса и проблем на работе. С видом героев они тушат множественные пожары по всем фронтам и предотвращают катастрофу в последний момент.
Возможно, вы даже смотрите на них и говорите: «Ах, как(ой/ая) молодец! Ведь столько дел, а всё успевает, везде помогает. Овертаймит постоянно, по вечерам, ночам, выходным. Сколько сил и самоотверженности у человека!».
Если вдруг вы из тех, кто по наивности так думает, то рекомендую вам немножко внимательнее вглядеться в работу этих людей. Не слушайте, как они трубят о том, что сегодня потушили три пожара, а вчера победили вселенскую энтропию. Смотрите на то, кто зажигал эти пожары и откуда пошла энтропия. Результат вас может сильно удивить.
Окажется, что во многих случаях герои сами и разжигают пожары, которые затем победоносно тушат. Разжигают не то что прям со зла, а скорее своей неорганизованностью, безответственностью и несистемным подходом к задачам. У таких людей все сроки закончились вчера, ТЗ только на словах, а ответов на вопросы не дождешься, ибо они уже на другой пожар умчались. Это не потому, что они в какой-то такой особенной вселенной живут, или какая-то сфера деятельности настолько специфичная. А потому что такой вот подход к организации своей работы, а заодно и тех, кто от нее зависит.
True Heroes
Для разнообразия попробуйте поискать среди своих коллег других героев невидимого фронта. Они не слагают славных песен о своих подвигах. Они не уходят с работы глубокой ночью. Они не пишут вам письма на выходных. Они всегда вас предупреждают заранее. Они планируют свою работу и согласовывают её с вами. Они всегда вам готовы ответить на ваши вопросы. Они просто делают всё вовремя и уходят домой (в закат). На мой взгляд, именно они – настоящие герои в работе.
Итог
Прекратите поощрять разжигателей пожаров. Думайте над своей работой, над рабочими процессами, не пускайте всё на самотек, уважайте чужое время и труд. Будьте настоящими героями!
Мой твиттерский товарищ Виктор завел себе телеграм канал https://news.1rj.ru/str/telega_vvn33 который я вам и хотел бы посоветовать.
Айтишник, который пишет не только про ИТ, но и про ЖКХ, урбанистику, образование и т.д. Не теоретик(как я), а практик, очень многое делающий своими руками. Приходите к нему за новым опытом и идеями.
Айтишник, который пишет не только про ИТ, но и про ЖКХ, урбанистику, образование и т.д. Не теоретик(как я), а практик, очень многое делающий своими руками. Приходите к нему за новым опытом и идеями.
Telegram
Телеграммы Виктора
Пишу про:
IT, IoT, образование, наука, урбанистика и ЖКХ. И всякое разное, но интересное/полезное.
@Vvolchek
IT, IoT, образование, наука, урбанистика и ЖКХ. И всякое разное, но интересное/полезное.
@Vvolchek
Не хотел ничего писать про удаленку в целом, т.к. сейчас и так об этом вещают из каждого утюга.
А уж какие-то видео снимать я тем более не собирался.
Однако на работе меня попросили снять коротенькое видео для коллег, которые только перешли на удаленку, и я в этой просьбе не отказал. Изначально я не планировал его никуда выкладывать, но потом подумал: а зачем моему труду пропадать? Так что решил поделиться с вами, вдруг кто-то вынесет для себя какую-нибудь полезную мысль.
Видео попросили сделать очень коротким, так что я там рассказал необходимый минимум, не углубляясь в детали. Конечно, это тема куда более широкая и требует долгого разговора, и даже не одного.
Видосик тут https://www.youtube.com/watch?v=ua9rK4L7W2s
P.S. Да, я знаю, что звук плохой. Да, если бы я на самом деле планировал записывать видео для большой аудитории, я бы с этим что-то сделал. Будем считать, что это принцип Парето, где 20% усилий дают 80% результата:)
А уж какие-то видео снимать я тем более не собирался.
Однако на работе меня попросили снять коротенькое видео для коллег, которые только перешли на удаленку, и я в этой просьбе не отказал. Изначально я не планировал его никуда выкладывать, но потом подумал: а зачем моему труду пропадать? Так что решил поделиться с вами, вдруг кто-то вынесет для себя какую-нибудь полезную мысль.
Видео попросили сделать очень коротким, так что я там рассказал необходимый минимум, не углубляясь в детали. Конечно, это тема куда более широкая и требует долгого разговора, и даже не одного.
Видосик тут https://www.youtube.com/watch?v=ua9rK4L7W2s
P.S. Да, я знаю, что звук плохой. Да, если бы я на самом деле планировал записывать видео для большой аудитории, я бы с этим что-то сделал. Будем считать, что это принцип Парето, где 20% усилий дают 80% результата:)
YouTube
Работа и здоровье на удаленке
Очень короткий (потому все освещенные темы глубоко не раскрыты в этом видео) рассказ о том как эффективно работать на удаленке и при этом заботиться о своём здоровье.
За подобной полезной информацией приходите ко мне в телеграм канал https://news.1rj.ru/str/general_it_talks…
За подобной полезной информацией приходите ко мне в телеграм канал https://news.1rj.ru/str/general_it_talks…
Постановка задач. Чайка-менеджмент. Микроменеджмент
Сегодня хотелось бы рассмотреть две часто встречающиеся крайности при постановке задач, а также подумать, как найти некий срединный путь в этом деле.
Проблема №1. Чайка менеджмент
Что это такое? Это когда менеджер, подобно чайке, внезапно прилетел, хаотично пошумел, нагадил кое-как задачами и улетел, а работник остался с этим всем наедине. Ему надо разгрести, прибрать, упорядочить и как-то разобраться. Чайка-менеджер вернется к нему уже за результатом. Ну и чтобы еще пошуметь, конечно :)
Кроме очевидной проблемы неизбывной тоски подчиненного, есть еще и проблема получения конечного результата в этом случае. Менеджер в процессе работы ничего не контролирует и просто надеется, что произойдет чудо, его сотрудники не только родят из хаоса стройные задачи, но и выполнят их как надо и в срок.
Неожиданный спойлер: этого может и не произойти.
Проблема №2. Микроменеджмент
Что это такое? Это когда менеджер контролирует каждый шаг, чих и вздох сотрудника. Перепроверяет за ним ежечасно всё до мельчайших подробностей. Возможно, навязывает ему свой взгляд, свои методы и свои практики даже на самые крохотные задачи.
Тут проблема сотрудника в том, что он не чувствует:
а) доверия со стороны руководства. «Раз каждый чих контролируют, значит не доверяют»;
б) возможности раскрыть свой потенциал. Ничего нельзя придумать и сделать, любые решения даже по пустяковым вопросам навязаны сверху, а работник – просто робот-исполнитель.
У руководителя в данном случае тоже есть проблема. Он просто физически не может каждого проконтролировать и сделать при этом еще и свое дело. Следовательно, где-то работа потеряет в качестве, а заодно и рабочий день руководителя удлинится раза в два.
Срединный путь
Необходимо научиться доверять своим сотрудникам. Да, может быть, сейчас вы лучше них знаете, что и как надо сделать, но позвольте им научиться. Как только они научатся, вам сразу станет легче работать.
Необходимо уважать время и работу сотрудников. Проявите дисциплину в своих действиях, сформулируйте задачи, убедитесь, что люди их поняли, запланируйте дела чуть дальше, чем на 7.5 минут.
Найдите компромисс в контроле действий работника. Не бросайте всё на самотек, но и не дышите ему в затылок ежечасно. Оговорите с ним задачу и какие-то контрольные точки, в которые либо вы к нему придете и попросите показать промежуточный или финальный результат, или он вам доложит. Держите руку на пульсе. Чем раньше вы выявите проблемы, тем дешевле будет цена их устранения.
Сегодня хотелось бы рассмотреть две часто встречающиеся крайности при постановке задач, а также подумать, как найти некий срединный путь в этом деле.
Проблема №1. Чайка менеджмент
Что это такое? Это когда менеджер, подобно чайке, внезапно прилетел, хаотично пошумел, нагадил кое-как задачами и улетел, а работник остался с этим всем наедине. Ему надо разгрести, прибрать, упорядочить и как-то разобраться. Чайка-менеджер вернется к нему уже за результатом. Ну и чтобы еще пошуметь, конечно :)
Кроме очевидной проблемы неизбывной тоски подчиненного, есть еще и проблема получения конечного результата в этом случае. Менеджер в процессе работы ничего не контролирует и просто надеется, что произойдет чудо, его сотрудники не только родят из хаоса стройные задачи, но и выполнят их как надо и в срок.
Неожиданный спойлер: этого может и не произойти.
Проблема №2. Микроменеджмент
Что это такое? Это когда менеджер контролирует каждый шаг, чих и вздох сотрудника. Перепроверяет за ним ежечасно всё до мельчайших подробностей. Возможно, навязывает ему свой взгляд, свои методы и свои практики даже на самые крохотные задачи.
Тут проблема сотрудника в том, что он не чувствует:
а) доверия со стороны руководства. «Раз каждый чих контролируют, значит не доверяют»;
б) возможности раскрыть свой потенциал. Ничего нельзя придумать и сделать, любые решения даже по пустяковым вопросам навязаны сверху, а работник – просто робот-исполнитель.
У руководителя в данном случае тоже есть проблема. Он просто физически не может каждого проконтролировать и сделать при этом еще и свое дело. Следовательно, где-то работа потеряет в качестве, а заодно и рабочий день руководителя удлинится раза в два.
Срединный путь
Необходимо научиться доверять своим сотрудникам. Да, может быть, сейчас вы лучше них знаете, что и как надо сделать, но позвольте им научиться. Как только они научатся, вам сразу станет легче работать.
Необходимо уважать время и работу сотрудников. Проявите дисциплину в своих действиях, сформулируйте задачи, убедитесь, что люди их поняли, запланируйте дела чуть дальше, чем на 7.5 минут.
Найдите компромисс в контроле действий работника. Не бросайте всё на самотек, но и не дышите ему в затылок ежечасно. Оговорите с ним задачу и какие-то контрольные точки, в которые либо вы к нему придете и попросите показать промежуточный или финальный результат, или он вам доложит. Держите руку на пульсе. Чем раньше вы выявите проблемы, тем дешевле будет цена их устранения.
👍2❤1
Магия в коде: хорошо или плохо
В интернетах часто ведутся войны про то как ужасно, или наоборот удобно, когда в коде много «магии», синтаксического сахара и прочих неявных вещей, упрощающих разработку. Сегодня я посижу на обоих этих стульях.
Магия в коде — это плохо
Есть мнение, что чем меньше магии (неочевидных, неявных вещей) в коде, тем лучше. В большинстве случаев я с этим абсолютно согласен.
Пайтон дзен учит нас, что «явное лучше неявного» не просто так. Чем яснее и очевиднее код, тем проще его читать и поддерживать, а ведь именно это занимает большую часть времени программиста. Чем меньше нужно знать каких-то дополнительных соглашений по работе кода, чем меньше документации надо изучить, прежде чем понять, что тут нафиг вообще происходит и т.д., тем проще.
Магия в коде — это удобно
Однако надо помнить, что эти неочевидные вещи придумываются не просто так. Зачастую они позволяют сильно сократить код, упростить его написание и избавить вас от реализации неких своих велосипедов, предоставляя вам уже готовые красивые решения.
Деритес
Часто вижу, как люди воюют за и против магии, используя только аргументы типа «удобно», «понятно», «концептуально», «красиво», «руки из жопы» и т.д.
Я же предлагаю в первую очередь взглянуть на проект, который надо сделать, и на команду, которая им займется.
Если это сплоченная команда, которая хорошо работает в рамках установленных стандартов, то почему бы и не взять инструмент, несущий много упрощений. Они сильно помогут, стоит только договориться в команде, как их использовать.
Если частая ротация кадров и договариваться сложно, то лучше уж пойти явным путем, т.к. обычно он примерно один, и в него вникнуть проще, а магию использовать можно по-разному. Зоопарк и смятение в проекте нам не нужно.
Если проект надо побыстрее сделать и поддержка будет не сильно большая, то магия вам в помощь, быстро разработайте и забудьте.
Если крупный проект, серьезная поддержка, то берите более понятные инструменты, они и ясности добавят, и гибкости.
Итог
Не зацикливайтесь на инструментах и технологиях. Смотрите шире, анализируйте настоящее и потенциальное будущее проекта. Помните, что не инструмент всю работу делает, а команда.
В интернетах часто ведутся войны про то как ужасно, или наоборот удобно, когда в коде много «магии», синтаксического сахара и прочих неявных вещей, упрощающих разработку. Сегодня я посижу на обоих этих стульях.
Магия в коде — это плохо
Есть мнение, что чем меньше магии (неочевидных, неявных вещей) в коде, тем лучше. В большинстве случаев я с этим абсолютно согласен.
Пайтон дзен учит нас, что «явное лучше неявного» не просто так. Чем яснее и очевиднее код, тем проще его читать и поддерживать, а ведь именно это занимает большую часть времени программиста. Чем меньше нужно знать каких-то дополнительных соглашений по работе кода, чем меньше документации надо изучить, прежде чем понять, что тут нафиг вообще происходит и т.д., тем проще.
Магия в коде — это удобно
Однако надо помнить, что эти неочевидные вещи придумываются не просто так. Зачастую они позволяют сильно сократить код, упростить его написание и избавить вас от реализации неких своих велосипедов, предоставляя вам уже готовые красивые решения.
Деритес
Часто вижу, как люди воюют за и против магии, используя только аргументы типа «удобно», «понятно», «концептуально», «красиво», «руки из жопы» и т.д.
Я же предлагаю в первую очередь взглянуть на проект, который надо сделать, и на команду, которая им займется.
Если это сплоченная команда, которая хорошо работает в рамках установленных стандартов, то почему бы и не взять инструмент, несущий много упрощений. Они сильно помогут, стоит только договориться в команде, как их использовать.
Если частая ротация кадров и договариваться сложно, то лучше уж пойти явным путем, т.к. обычно он примерно один, и в него вникнуть проще, а магию использовать можно по-разному. Зоопарк и смятение в проекте нам не нужно.
Если проект надо побыстрее сделать и поддержка будет не сильно большая, то магия вам в помощь, быстро разработайте и забудьте.
Если крупный проект, серьезная поддержка, то берите более понятные инструменты, они и ясности добавят, и гибкости.
Итог
Не зацикливайтесь на инструментах и технологиях. Смотрите шире, анализируйте настоящее и потенциальное будущее проекта. Помните, что не инструмент всю работу делает, а команда.
Лучшее – враг хорошего
Практически всех нас с детства учат, что все нужно делать максимально хорошо.
Учиться на одни пятерки, быть лучшим из детей в своем творческом кружке. Хвалят тоже только за пятерки (если у вас было не так – я очень рад за вас, одной психологической травмой у вас меньше), повышенную стипендию платят только за пятерки, отправляют бесплатно в лагерь от универа лучшего студента (или друзей старосты, конечно) и т. д.
Мотивационные примеры нам из каждого утюга вещают тоже о самых лучших из лучших из лучших. Спортсмены мирового уровня, миллиардеры-трудоголики-перфекционисты, известные на весь космос актеры. Все они самоотверженно трудились, выжимали все 100% (кое-кто и 146 смог) и добились выдающихся результатов, значит и тебе нужно так же.
Не буду тут спорить о том, что не каждому быть миллиардером или олимпийским чемпионом.
Хочу рассмотреть, как это влияет на работу в ИТ.
В ИТ молодой пламяокий айтишник, начитавшись книг про SOLID, Линуса Торвальдса и Павла Дурова, сел писать код.
Ммммм…. Нет, сел он не писать, а раздумывать над тем, как же написать, чтобы оно было максимально круто, элегантно, расширяемо, поддерживаемо, респектово (другие же программисты посмотрят). Пока он сидит в раздумьях, фича всё никак не релизится. У конкурентов вылезла хоть какая-то кривая-косая, а пламяокий всё размышляет.
Наконец он придумал крутейшую архитектуру, написал код и релизнул фичу. Оказалось, фичей не пользуются, потому что уже привыкли это юзать у конкурентов, а ваш поезд уже ушел.
Интересный факт. Английский вариант поговорки "Лучшее – враг хорошего" это "Done is better than perfect". Он довольно наглядно демонстрирует то, о чем я хочу сказать.
Конечно, справедливо возразить, что это крайний случай, что такое бывает редко, что если наговнокодить быстренько, то потом сложно развивать и поддерживать стабильность такого проекта и т. д. Да, всё это так. Однако я клоню к тому, что надо смотреть на ситуацию. Делать хорошо и основательно там, где требуется долгосрочная большая работа, а там, где проект поживет месяц без изменений и выкинется в мусорку - можно бы и поступиться святейшими паттернами Банды Четырех и вот этим вот всем прочим.
Когда пламя в моих глазах потухло, и я стал смотреть более спокойно на компромиссные решения, я решил больше ориентироваться на принцип Парето «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата».
Выделил из работы те 20% усилий, которые принесут основной результат, сделал их, а дальше смотрю, нужно ли вообще продолжать что-то делать. Если нужно дотачивать до идеала – не проблема, дорабатываю оставшиеся 80%. Однако, если при трезвом взгляде окажется, что и так хорошо, что можно больше пользы (зачастую и прибыли) принести в другом месте, то зачем впаливать вчетверо больше усилий в незначительный профит?
Итог
Немножко притушите пыл идеализма, смотрите на работу и профит от неё критически. Помните, бизнес вам платит и хвалит не когда вы максимально идеальный код написали, а когда от вашей работы пришло больше денежек в копилочку. Кто это понял, тому и в его копилочку тоже побольше достанется.
Практически всех нас с детства учат, что все нужно делать максимально хорошо.
Учиться на одни пятерки, быть лучшим из детей в своем творческом кружке. Хвалят тоже только за пятерки (если у вас было не так – я очень рад за вас, одной психологической травмой у вас меньше), повышенную стипендию платят только за пятерки, отправляют бесплатно в лагерь от универа лучшего студента (или друзей старосты, конечно) и т. д.
Мотивационные примеры нам из каждого утюга вещают тоже о самых лучших из лучших из лучших. Спортсмены мирового уровня, миллиардеры-трудоголики-перфекционисты, известные на весь космос актеры. Все они самоотверженно трудились, выжимали все 100% (кое-кто и 146 смог) и добились выдающихся результатов, значит и тебе нужно так же.
Не буду тут спорить о том, что не каждому быть миллиардером или олимпийским чемпионом.
Хочу рассмотреть, как это влияет на работу в ИТ.
В ИТ молодой пламяокий айтишник, начитавшись книг про SOLID, Линуса Торвальдса и Павла Дурова, сел писать код.
Ммммм…. Нет, сел он не писать, а раздумывать над тем, как же написать, чтобы оно было максимально круто, элегантно, расширяемо, поддерживаемо, респектово (другие же программисты посмотрят). Пока он сидит в раздумьях, фича всё никак не релизится. У конкурентов вылезла хоть какая-то кривая-косая, а пламяокий всё размышляет.
Наконец он придумал крутейшую архитектуру, написал код и релизнул фичу. Оказалось, фичей не пользуются, потому что уже привыкли это юзать у конкурентов, а ваш поезд уже ушел.
Интересный факт. Английский вариант поговорки "Лучшее – враг хорошего" это "Done is better than perfect". Он довольно наглядно демонстрирует то, о чем я хочу сказать.
Конечно, справедливо возразить, что это крайний случай, что такое бывает редко, что если наговнокодить быстренько, то потом сложно развивать и поддерживать стабильность такого проекта и т. д. Да, всё это так. Однако я клоню к тому, что надо смотреть на ситуацию. Делать хорошо и основательно там, где требуется долгосрочная большая работа, а там, где проект поживет месяц без изменений и выкинется в мусорку - можно бы и поступиться святейшими паттернами Банды Четырех и вот этим вот всем прочим.
Когда пламя в моих глазах потухло, и я стал смотреть более спокойно на компромиссные решения, я решил больше ориентироваться на принцип Парето «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата».
Выделил из работы те 20% усилий, которые принесут основной результат, сделал их, а дальше смотрю, нужно ли вообще продолжать что-то делать. Если нужно дотачивать до идеала – не проблема, дорабатываю оставшиеся 80%. Однако, если при трезвом взгляде окажется, что и так хорошо, что можно больше пользы (зачастую и прибыли) принести в другом месте, то зачем впаливать вчетверо больше усилий в незначительный профит?
Итог
Немножко притушите пыл идеализма, смотрите на работу и профит от неё критически. Помните, бизнес вам платит и хвалит не когда вы максимально идеальный код написали, а когда от вашей работы пришло больше денежек в копилочку. Кто это понял, тому и в его копилочку тоже побольше достанется.
Нормально договаривайся – нормально будет
Думаю, каждый из нас сталкивался с ситуацией, когда договоренности не исполняются. Можно сколько угодно жаловаться на необязательность людей, бомбить от безответственного подхода и так далее, но проблему это не решит.
Хотелось бы поделиться с вами капитанским чеклистом, который я использую при согласовании договоренностей с другими людьми. Он позволяет мне минимизировать риски бестолкового поведения.
Кто делает
Нужно явно договориться, кто именно является исполнителем.
Что делает
Определить, что именно должен делать исполнитель.
Когда делает
Обязательно обговорите сроки. Когда должно быть сделано, когда промежуточный контроль исполнения, и вот это вот всё.
Кто ответственный
Бывает, что исполнитель и ответственный - это разные лица, так что непременно явно зафиксируйте ответственного. Например, исполнитель - это программист Вася, а ответственный за всё мероприятие - менеджер Петя. Вот как только Петя явно подтвердил, что он ответственный, он автоматически получил бонус к мотивации на исполнение всех этих договоренностей.
Зафиксировано на письме
Ни в коем случае не оставляйте договоренности устными. С этого всегда можно легко соскочить (или наоборот накинуть лишней работы) под крики «Да мы не так договаривались! Да ты всё не так понял(а)! Да это вообще не про то!».
Фиксируйте всё письменно и публично для всех договаривающихся сторон. По этим письменным артефактам всегда можно найти и раскопать всю историю общения. Плюс это дополнительно мотивирует людей вас не обманывать: всё надежно задокументировано, а они публично согласились на выполнение своей части договоренности.
Итог
Применяйте этот способ, не думайте наивно «Да мы же тут братишки, все друг другу доверяют, как же это я так буду сомневаться? Да что обо мне подумают, если я попрошу вот так письменно?».
Что о вас подумают? Что вы очень хотите, чтобы дело было сделано без лишних организационных проблем.
Думаю, каждый из нас сталкивался с ситуацией, когда договоренности не исполняются. Можно сколько угодно жаловаться на необязательность людей, бомбить от безответственного подхода и так далее, но проблему это не решит.
Хотелось бы поделиться с вами капитанским чеклистом, который я использую при согласовании договоренностей с другими людьми. Он позволяет мне минимизировать риски бестолкового поведения.
Кто делает
Нужно явно договориться, кто именно является исполнителем.
Что делает
Определить, что именно должен делать исполнитель.
Когда делает
Обязательно обговорите сроки. Когда должно быть сделано, когда промежуточный контроль исполнения, и вот это вот всё.
Кто ответственный
Бывает, что исполнитель и ответственный - это разные лица, так что непременно явно зафиксируйте ответственного. Например, исполнитель - это программист Вася, а ответственный за всё мероприятие - менеджер Петя. Вот как только Петя явно подтвердил, что он ответственный, он автоматически получил бонус к мотивации на исполнение всех этих договоренностей.
Зафиксировано на письме
Ни в коем случае не оставляйте договоренности устными. С этого всегда можно легко соскочить (или наоборот накинуть лишней работы) под крики «Да мы не так договаривались! Да ты всё не так понял(а)! Да это вообще не про то!».
Фиксируйте всё письменно и публично для всех договаривающихся сторон. По этим письменным артефактам всегда можно найти и раскопать всю историю общения. Плюс это дополнительно мотивирует людей вас не обманывать: всё надежно задокументировано, а они публично согласились на выполнение своей части договоренности.
Итог
Применяйте этот способ, не думайте наивно «Да мы же тут братишки, все друг другу доверяют, как же это я так буду сомневаться? Да что обо мне подумают, если я попрошу вот так письменно?».
Что о вас подумают? Что вы очень хотите, чтобы дело было сделано без лишних организационных проблем.
Письменные daily standups (сорри, я билингв)
Если не знаешь, что это за стендапы такие – беги сначала прочитать об этом, например, сюда https://habr.com/ru/post/456980/ (или в гугл), а потом возвращайся.
Устно
В связи с карантином, многие команды, только осваивающие удаленку, начинают проводить ежедневные стендапы в видео звонках (zoom, skype, hangouts). В чем я вижу минусы этого подхода?
- Нужно всем собраться в одно и то же время. Это и в одном часовом поясе порой сложно, а в разных – тем более.
- Нужно всем надеть парадную футболку, помыть голову, а то и подкраситься (никакого сексизма, пол подкрашиваемого не указан!). Футболка может быть в стирке, воду отключили, а магазин косметики дальше 100 метров от дома, без пропуска и не прошмыгнешь туда.
- Общение в зуме несколько отличается от живого общения и немного удлиняется из-за накладок с тем, что оба начинают говорить одновременно, у кого-то глохнет микрофон, сверлит сосед, рожает кошка.
- Созвон с несколькими людьми по делу часто превращается в дело + N времени на словоблудие, пересказ вчерашней серии {{название_сериала}} и просто прибаутки. Тут требуются дополнительные усилия по модерации всего этого мероприятия.
- Завтра можно полностью или частично забыть, кто что рассказывает сегодня.
Письменно
Я хочу поделиться тем, как мы в своей распределенной команде проводим стендапы.
Письменное общение у нас происходит в слаке. Поэтому для стендапов мы выделили отдельный канал. В него каждое утро все сотрудники пишут 2-3 пункта: над какими задачами работал вчера, над какими планирует работать сегодня и (опционально) есть ли какие-то проблемы, мешающие его работе.
Флудить в этом канале, обсуждать чьи-то задачи или проблемы запрещено. Этот канал строго для агрегации информации о состоянии дел. Остальные обсуждения должны вестись в соответствующих тематических каналах.
Такой формат позволяет устранить все указанные мной минусы:
- Асинхронный формат. Не приходится куче людей подстраиваться под конкретное время.
- Можно находиться в повседневной, а не парадной футболке.
- Написать и прочитать - это очень быстро. Если у тебя в это время родит кошка – никто и не заметит!
- Словоблудие отсутствует как класс, потому что на уровне регламента запрещены любые другие обсуждения и в них на письме скатиться значительно сложнее, чем в устной беседе зацепиться языками.
- Ничего не забывается и не теряется, можно открутить канал на любой день, перечитать и проследить за динамикой работ.
Если не знаешь, что это за стендапы такие – беги сначала прочитать об этом, например, сюда https://habr.com/ru/post/456980/ (или в гугл), а потом возвращайся.
Устно
В связи с карантином, многие команды, только осваивающие удаленку, начинают проводить ежедневные стендапы в видео звонках (zoom, skype, hangouts). В чем я вижу минусы этого подхода?
- Нужно всем собраться в одно и то же время. Это и в одном часовом поясе порой сложно, а в разных – тем более.
- Нужно всем надеть парадную футболку, помыть голову, а то и подкраситься (никакого сексизма, пол подкрашиваемого не указан!). Футболка может быть в стирке, воду отключили, а магазин косметики дальше 100 метров от дома, без пропуска и не прошмыгнешь туда.
- Общение в зуме несколько отличается от живого общения и немного удлиняется из-за накладок с тем, что оба начинают говорить одновременно, у кого-то глохнет микрофон, сверлит сосед, рожает кошка.
- Созвон с несколькими людьми по делу часто превращается в дело + N времени на словоблудие, пересказ вчерашней серии {{название_сериала}} и просто прибаутки. Тут требуются дополнительные усилия по модерации всего этого мероприятия.
- Завтра можно полностью или частично забыть, кто что рассказывает сегодня.
Письменно
Я хочу поделиться тем, как мы в своей распределенной команде проводим стендапы.
Письменное общение у нас происходит в слаке. Поэтому для стендапов мы выделили отдельный канал. В него каждое утро все сотрудники пишут 2-3 пункта: над какими задачами работал вчера, над какими планирует работать сегодня и (опционально) есть ли какие-то проблемы, мешающие его работе.
Флудить в этом канале, обсуждать чьи-то задачи или проблемы запрещено. Этот канал строго для агрегации информации о состоянии дел. Остальные обсуждения должны вестись в соответствующих тематических каналах.
Такой формат позволяет устранить все указанные мной минусы:
- Асинхронный формат. Не приходится куче людей подстраиваться под конкретное время.
- Можно находиться в повседневной, а не парадной футболке.
- Написать и прочитать - это очень быстро. Если у тебя в это время родит кошка – никто и не заметит!
- Словоблудие отсутствует как класс, потому что на уровне регламента запрещены любые другие обсуждения и в них на письме скатиться значительно сложнее, чем в устной беседе зацепиться языками.
- Ничего не забывается и не теряется, можно открутить канал на любой день, перечитать и проследить за динамикой работ.
Хабр
Stand-up, Scrum, Daily meetings — что это и для чего
Часто стал замечать, что люди все больше и больше перетягивают методологии и практики из IT сферы в производственные, банковские, сферы услуг и прочие. Одной из самых распространенных «заимствованных»...
Надо ли писать документацию?
Перефразирую известную фразу про бэкапы. Люди делятся на два типа. На тех, кто не пишет доки, и тех, кто уже пишет.
Это мое мнение по большинству вопросов, связанных с документацией.
Плюсы
На мой взгляд, документация весьма полезна, хоть и требует определенного времени, дисциплины и усилий.
- У вас в команде есть человек, который знает, как делать одну штуку, и вы ходите всей толпой к нему, а когда он увольняется, плачете горючими слезами? Пусть напишет доку и отвечает страждущим ссылкой на доку, а потом увольняется сколько угодно. Его знания останутся в веках на письме.
- Вы делаете набор типовых действий раз в месяц-полгода-год и постоянно забываете, как же там правильно? Напишите доку с правильным алгоритмом действий и спите спокойно, выкинув из головы боязнь что-то забыть.
- Вы запрограммировали сложную задачу с развесистой бизнес логикой, а теперь ваш коллега приуныл, пытаясь внести правки? Или вы сами приуныли, потому что запрограммировали полгода назад и теперь смотрите на этот код, словно в первый раз? Напишите доку по этой бизнес логике сразу, порисуйте диаграммы всякие и не надо будет держать в голове все знания годами (а вы и не удержите).
- Вы договорились в команде делать так, а через месяц коллеги начали делать иначе (они забыли), а новички - еще иначе (они и не знали)? После того как договорились, напишите доку по регламенту и выдавайте её всем коллегам и новичкам. Тогда старые коллеги не забудут, а новые будут легко онбордиться.
Таких примеров можно приводить море.
Минусы
Однако есть и определенные сложности в написании документации:
- Нужно уметь понятно и структурированно излагать свои мысли письменно.
- Нужно иметь определенную долю дисциплины и времени, чтобы регулярно актуализировать доку. В противном случае устаревшая документация будет еще хуже, чем никакая.
- Бывают случаи, когда написание доки - это действительно излишняя трата времени. Например, вы делаете проект, отдаете его заказчику, получаете деньги и больше с ним дела не имеете. Или вы делаете проект, который провисит 2 месяца в проде и закроется, а подобный делать вам больше не понадобится (запаситесь хрустальным шаром для точного предсказания будущего).
Итог
Мое мнение, что плюсы ощутимо перевешивают минусы. Поэтому, если ваш менеджер говорит вам, что дока не нужна и это только трата времени, и вам не за это платят, вы можете помочь ему разобраться с ситуацией и показать этот пост. Если это не помогло, согласитесь с ним и не пишите доку, а потом, когда команда наступит во все грабли из раздела плюсов, дайте ему перечитать этот пост еще раз.
Перефразирую известную фразу про бэкапы. Люди делятся на два типа. На тех, кто не пишет доки, и тех, кто уже пишет.
Это мое мнение по большинству вопросов, связанных с документацией.
Плюсы
На мой взгляд, документация весьма полезна, хоть и требует определенного времени, дисциплины и усилий.
- У вас в команде есть человек, который знает, как делать одну штуку, и вы ходите всей толпой к нему, а когда он увольняется, плачете горючими слезами? Пусть напишет доку и отвечает страждущим ссылкой на доку, а потом увольняется сколько угодно. Его знания останутся в веках на письме.
- Вы делаете набор типовых действий раз в месяц-полгода-год и постоянно забываете, как же там правильно? Напишите доку с правильным алгоритмом действий и спите спокойно, выкинув из головы боязнь что-то забыть.
- Вы запрограммировали сложную задачу с развесистой бизнес логикой, а теперь ваш коллега приуныл, пытаясь внести правки? Или вы сами приуныли, потому что запрограммировали полгода назад и теперь смотрите на этот код, словно в первый раз? Напишите доку по этой бизнес логике сразу, порисуйте диаграммы всякие и не надо будет держать в голове все знания годами (а вы и не удержите).
- Вы договорились в команде делать так, а через месяц коллеги начали делать иначе (они забыли), а новички - еще иначе (они и не знали)? После того как договорились, напишите доку по регламенту и выдавайте её всем коллегам и новичкам. Тогда старые коллеги не забудут, а новые будут легко онбордиться.
Таких примеров можно приводить море.
Минусы
Однако есть и определенные сложности в написании документации:
- Нужно уметь понятно и структурированно излагать свои мысли письменно.
- Нужно иметь определенную долю дисциплины и времени, чтобы регулярно актуализировать доку. В противном случае устаревшая документация будет еще хуже, чем никакая.
- Бывают случаи, когда написание доки - это действительно излишняя трата времени. Например, вы делаете проект, отдаете его заказчику, получаете деньги и больше с ним дела не имеете. Или вы делаете проект, который провисит 2 месяца в проде и закроется, а подобный делать вам больше не понадобится (запаситесь хрустальным шаром для точного предсказания будущего).
Итог
Мое мнение, что плюсы ощутимо перевешивают минусы. Поэтому, если ваш менеджер говорит вам, что дока не нужна и это только трата времени, и вам не за это платят, вы можете помочь ему разобраться с ситуацией и показать этот пост. Если это не помогло, согласитесь с ним и не пишите доку, а потом, когда команда наступит во все грабли из раздела плюсов, дайте ему перечитать этот пост еще раз.
❤1