Письменные 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
Надо ли писать тесты?
В прошлом посте я обсудил документацию, которую неплохо бы писать в большинстве случаев.
Сегодня поговорю про тесты.
На мой взгляд, с тестами всё обстоит менее радикально, чем с документацией. Т.к. я работаю в веб разработке, то учтите, что мои рассуждения распространяются только на этот сегмент. Расскажу свои мысли исходя из практики. Не хочу теоретизировать и лезть в другие, малознакомые области.
Тесты надо писать
Когда у вас много разветвленной бизнес логики и проект постоянно развивается. Тесты помогут быть немного более уверенными при внесении изменений в уже существующий код. И еще они сильно сэкономят вам время на тестировании всех юзер кейсов приложения.
Если ваш менеджер говорит, что написание тестов - это трата времени и вообще вам тут за фичи платят, а не за тесты, то покажите ему, сколько времени стоит проверить все юзер кейсы руками (допустим, минут 30-60, но бывает, что и много часов), а потом запустите тесты, и они пробегут у вас за 3 минутки. Если менеджеру не хватит сообразительности посчитать этот несложный математический пример, то кивните и не пишите тесты. Спустя пару месяцев, две еле выпущенные фичи и пяток багов на проде повторите еще раз предыдущую итерацию. Возможно, в этот раз сработает лучше.
Тесты не надо писать
- Если вы у вас особой логики нет, а вы делаете инфосайтик, где просто выводите очередной блок новостей из базы.
- Если вы один раз сделали проект и забыли про него. Поддерживать не надо.
- Если вы просто хотите написать тест ради теста, чтобы почувствовать себя более программистским программистом, ведь в твиттере, на ютубе и хабре говорят, что кто не тестит – тот не программист.
Дымовой тест
Иной раз вполне достаточно написать самый минимальный набор тестов, который будет подтверждать общую работоспособность вашего приложения. Например, у вас есть чудесный одностраничный сайт автошколы, на котором есть расписание и три рекламных блока. Напишите тест, который проверит, что страница отдается со статусом 200 и получает контент из футера (то есть загружается до конца) и вам для спокойствия этого будет более чем достаточно.
Если развернуть мысль немножко шире, то дымовые тесты вы конечно можете писать не только для тривиальных проектов, но и для сложных. В этом случае сначала запускайте их, чтобы проверить, что приложение базово работоспособное, а потом уже оставшийся мильён тестов, чтобы проверять детали.
Итог
Смотрите сами, насколько целесообразно написать тесты и на что конкретно. Не слушайте радикалов, которые говорят, что нужно 100% покрытие кода тестами, или наоборот, тесты – трата времени. Думайте, анализируйте реальную пользу, которую можете получить.
В прошлом посте я обсудил документацию, которую неплохо бы писать в большинстве случаев.
Сегодня поговорю про тесты.
На мой взгляд, с тестами всё обстоит менее радикально, чем с документацией. Т.к. я работаю в веб разработке, то учтите, что мои рассуждения распространяются только на этот сегмент. Расскажу свои мысли исходя из практики. Не хочу теоретизировать и лезть в другие, малознакомые области.
Тесты надо писать
Когда у вас много разветвленной бизнес логики и проект постоянно развивается. Тесты помогут быть немного более уверенными при внесении изменений в уже существующий код. И еще они сильно сэкономят вам время на тестировании всех юзер кейсов приложения.
Если ваш менеджер говорит, что написание тестов - это трата времени и вообще вам тут за фичи платят, а не за тесты, то покажите ему, сколько времени стоит проверить все юзер кейсы руками (допустим, минут 30-60, но бывает, что и много часов), а потом запустите тесты, и они пробегут у вас за 3 минутки. Если менеджеру не хватит сообразительности посчитать этот несложный математический пример, то кивните и не пишите тесты. Спустя пару месяцев, две еле выпущенные фичи и пяток багов на проде повторите еще раз предыдущую итерацию. Возможно, в этот раз сработает лучше.
Тесты не надо писать
- Если вы у вас особой логики нет, а вы делаете инфосайтик, где просто выводите очередной блок новостей из базы.
- Если вы один раз сделали проект и забыли про него. Поддерживать не надо.
- Если вы просто хотите написать тест ради теста, чтобы почувствовать себя более программистским программистом, ведь в твиттере, на ютубе и хабре говорят, что кто не тестит – тот не программист.
Дымовой тест
Иной раз вполне достаточно написать самый минимальный набор тестов, который будет подтверждать общую работоспособность вашего приложения. Например, у вас есть чудесный одностраничный сайт автошколы, на котором есть расписание и три рекламных блока. Напишите тест, который проверит, что страница отдается со статусом 200 и получает контент из футера (то есть загружается до конца) и вам для спокойствия этого будет более чем достаточно.
Если развернуть мысль немножко шире, то дымовые тесты вы конечно можете писать не только для тривиальных проектов, но и для сложных. В этом случае сначала запускайте их, чтобы проверить, что приложение базово работоспособное, а потом уже оставшийся мильён тестов, чтобы проверять детали.
Итог
Смотрите сами, насколько целесообразно написать тесты и на что конкретно. Не слушайте радикалов, которые говорят, что нужно 100% покрытие кода тестами, или наоборот, тесты – трата времени. Думайте, анализируйте реальную пользу, которую можете получить.
👍1
Несколько идей для победы над синдромом самозванца
Чуть ли не каждый первый толковый специалист сталкивается так или иначе с синдромом самозванца. То есть он думает, что не он специалист, не молодец и всё такое, а ему просто повезло, он на самом деле знает и умеет мало, и его вот-вот разоблачат и с позором прогонят.
Борьба с этим может идти годами и зачастую полностью в ней не победить. И это, пожалуй, в какой-то мере норма. Однако можно притупить это чувство, принять и контролировать его. Здесь я приведу 3 простых идеи, которые могут помочь в данной проблеме.
№1. Думайте, с кем себя сравнивать
Да, мы все себя сравниваем с другими, от этого никуда не деться. Разумом мы лишь можем повлиять на то, с кем себя сравнивать. Как программист, я испытал большое облегчение, перестав себя сравнивать с чуваками, выезжающими на новейшем гироскутере на сцену топовой конфы и рассказывающими, как им удалось масштабироваться с 5000 серверов до 10000 за один чих кубернетеса и заработать при этом стомильенов долларов.
Это экстремум, ребята. Если вы не занимаетесь тем же самым, то и не надо сравнивать. Сравнивайте себя со своими коллегами, это намного более релевантный показатель.
Да, нужно мотивироваться тем, что когда-нибудь и вы выкатитесь на подобном топовом гироскутере (моноколесо? Самокат? Лонгборд? Что сейчас в тренде?) и будете блистать. Стремиться к лучшему - это замечательно, но в данный момент вы делаете то, что вы делаете, и сравнивать себя следует именно с такими же ребятами.
№2. Ведите логи своего профессионального развития
Я пишу подробный план своего профессионального развития на год-два вперед (периодически его корректирую, конечно). Какие книги прочитать, какие технологии потеребить, на какие курсы сходить, какие конференции посетить, какие проекты запилить и т. д.
В конце года обычно кажется: ну прошел год и прошел, вроде ровненько. А потом смотришь на этот список и говоришь себе: «Хммм… А я времени не терял, вон сколько сделал!». Это приободряет.
№3. Дневничок побед
Этот вариант – более мелкая версия прошлого. Если вы приунываете слишком быстро и ждать конца года, чтобы разок взглянуть в огого-план не хотите и не можете, то можно пойти экспресс путем. Записывайте в конце каждого дня 1-2-3 хоть и небольших, но победы. Закрыл баг, который долго висел и всем мозолил глаз, или наконец-то смог договориться с соседним отделом о плодотворном сотрудничестве, или релизнул проект, который долго пилил, или даже смог самостоятельно сделать кофе, не спрашивая у коллег «эцсамое, я что-то туплю, куда тут нажимать?».
Когда будет накатывать тоска – перечитывайте и вспоминайте. Каждый день у вас были победы, умейте это ценить.
Итог
Синдром самозванца есть у многих, это нормально. Умейте держать его в узде, цените себя и свои достижения. Не приунывайте!
Чуть ли не каждый первый толковый специалист сталкивается так или иначе с синдромом самозванца. То есть он думает, что не он специалист, не молодец и всё такое, а ему просто повезло, он на самом деле знает и умеет мало, и его вот-вот разоблачат и с позором прогонят.
Борьба с этим может идти годами и зачастую полностью в ней не победить. И это, пожалуй, в какой-то мере норма. Однако можно притупить это чувство, принять и контролировать его. Здесь я приведу 3 простых идеи, которые могут помочь в данной проблеме.
№1. Думайте, с кем себя сравнивать
Да, мы все себя сравниваем с другими, от этого никуда не деться. Разумом мы лишь можем повлиять на то, с кем себя сравнивать. Как программист, я испытал большое облегчение, перестав себя сравнивать с чуваками, выезжающими на новейшем гироскутере на сцену топовой конфы и рассказывающими, как им удалось масштабироваться с 5000 серверов до 10000 за один чих кубернетеса и заработать при этом стомильенов долларов.
Это экстремум, ребята. Если вы не занимаетесь тем же самым, то и не надо сравнивать. Сравнивайте себя со своими коллегами, это намного более релевантный показатель.
Да, нужно мотивироваться тем, что когда-нибудь и вы выкатитесь на подобном топовом гироскутере (моноколесо? Самокат? Лонгборд? Что сейчас в тренде?) и будете блистать. Стремиться к лучшему - это замечательно, но в данный момент вы делаете то, что вы делаете, и сравнивать себя следует именно с такими же ребятами.
№2. Ведите логи своего профессионального развития
Я пишу подробный план своего профессионального развития на год-два вперед (периодически его корректирую, конечно). Какие книги прочитать, какие технологии потеребить, на какие курсы сходить, какие конференции посетить, какие проекты запилить и т. д.
В конце года обычно кажется: ну прошел год и прошел, вроде ровненько. А потом смотришь на этот список и говоришь себе: «Хммм… А я времени не терял, вон сколько сделал!». Это приободряет.
№3. Дневничок побед
Этот вариант – более мелкая версия прошлого. Если вы приунываете слишком быстро и ждать конца года, чтобы разок взглянуть в огого-план не хотите и не можете, то можно пойти экспресс путем. Записывайте в конце каждого дня 1-2-3 хоть и небольших, но победы. Закрыл баг, который долго висел и всем мозолил глаз, или наконец-то смог договориться с соседним отделом о плодотворном сотрудничестве, или релизнул проект, который долго пилил, или даже смог самостоятельно сделать кофе, не спрашивая у коллег «эцсамое, я что-то туплю, куда тут нажимать?».
Когда будет накатывать тоска – перечитывайте и вспоминайте. Каждый день у вас были победы, умейте это ценить.
Итог
Синдром самозванца есть у многих, это нормально. Умейте держать его в узде, цените себя и свои достижения. Не приунывайте!
Моя проблема - это и твоя проблема
Рассмотрим ситуацию, когда действия одного человека (назовем его Бяка) приносят дискомфорт другому (пусть будет Няша) и настает время обсудить это. Няша приходит и говорит Бяке: «У меня дискомфорт, мне плохо, пожалуйста, так не делай».
Он в красках описывает свою проблему и надеется, что Бяка откроет свое доброе сердце, прислушается и перестанет делать, что делал. Во многих случаях этого не происходит, потому что «Чувак, это у тебя проблемы, ты и разбирайся. У меня своих хватает.»
Как я могу предложить действовать Няше в этом случае. Подавая свою проблему, помогите собеседнику понять, что и у него тоже могут возникнуть проблемы из-за этого. Тогда у Бяки резко поднимется мотивация что-то менять.
Пример
Вам пишут «Привет!», а потом тишина минут 5-10, собеседник что-то печатает. А вы уже отвлеклись от своей задачи, забыли, что делаете и тупите в экран, ожидая, чем же разрешится эта интрига. Вы шлете собеседнику ссылку на https://neprivet.ru/ и говорите, что он отвлекает, а ситуация повторяется.
Мое предложение сказать не просто «мне неудобно, пожалуйста, так не делай», а «ты мне пишешь “привет” и молчишь, я отвлекаюсь, трачу своё время, жду. Я раз отвлекся, два, пять, десять. Теперь у меня глаз замылился, я отвлекаться перестал не только на твой привет, но и дальнейшие сообщения твои могу пропустить. Думаю, никому из нас не хотелось бы ни писать в пустоту, ни пропускать сообщения, так что давай сразу формулировать нужную информацию в одно сообщение. Так будет проще и легче, и тебе, и мне».
Если он и дальше продолжает в том же духе - ну похоже придется и правда наглядно поигнорить его, пропустить пару срочных сообщений, а потом опять вернуться к этому разговору.
Когда Бяка будет понимать (или на словах, или уже дополнительно на деле, если он не очень хорошо слова воспринимает), что его поведение теперь и ему самому может доставить проблемы – он с большей вероятностью прекратит так себя вести.
Итог
Мало кто любит решать чужие проблемы, а вот свои – с удовольствием. Не стесняйтесь объяснить собеседнику, что он делает не только вам хуже, но и себе. Ну и будьте разумны, не жестите («Ах, ты так сделал?! Ну всё, чувак, у тебя теперь проблемы!!!»). Не угрожайте, просто помогите человеку понять все стороны проблемной ситуации. Не будьте Бяками, будьте Няшами:)
Рассмотрим ситуацию, когда действия одного человека (назовем его Бяка) приносят дискомфорт другому (пусть будет Няша) и настает время обсудить это. Няша приходит и говорит Бяке: «У меня дискомфорт, мне плохо, пожалуйста, так не делай».
Он в красках описывает свою проблему и надеется, что Бяка откроет свое доброе сердце, прислушается и перестанет делать, что делал. Во многих случаях этого не происходит, потому что «Чувак, это у тебя проблемы, ты и разбирайся. У меня своих хватает.»
Как я могу предложить действовать Няше в этом случае. Подавая свою проблему, помогите собеседнику понять, что и у него тоже могут возникнуть проблемы из-за этого. Тогда у Бяки резко поднимется мотивация что-то менять.
Пример
Вам пишут «Привет!», а потом тишина минут 5-10, собеседник что-то печатает. А вы уже отвлеклись от своей задачи, забыли, что делаете и тупите в экран, ожидая, чем же разрешится эта интрига. Вы шлете собеседнику ссылку на https://neprivet.ru/ и говорите, что он отвлекает, а ситуация повторяется.
Мое предложение сказать не просто «мне неудобно, пожалуйста, так не делай», а «ты мне пишешь “привет” и молчишь, я отвлекаюсь, трачу своё время, жду. Я раз отвлекся, два, пять, десять. Теперь у меня глаз замылился, я отвлекаться перестал не только на твой привет, но и дальнейшие сообщения твои могу пропустить. Думаю, никому из нас не хотелось бы ни писать в пустоту, ни пропускать сообщения, так что давай сразу формулировать нужную информацию в одно сообщение. Так будет проще и легче, и тебе, и мне».
Если он и дальше продолжает в том же духе - ну похоже придется и правда наглядно поигнорить его, пропустить пару срочных сообщений, а потом опять вернуться к этому разговору.
Когда Бяка будет понимать (или на словах, или уже дополнительно на деле, если он не очень хорошо слова воспринимает), что его поведение теперь и ему самому может доставить проблемы – он с большей вероятностью прекратит так себя вести.
Итог
Мало кто любит решать чужие проблемы, а вот свои – с удовольствием. Не стесняйтесь объяснить собеседнику, что он делает не только вам хуже, но и себе. Ну и будьте разумны, не жестите («Ах, ты так сделал?! Ну всё, чувак, у тебя теперь проблемы!!!»). Не угрожайте, просто помогите человеку понять все стороны проблемной ситуации. Не будьте Бяками, будьте Няшами:)
Как назначать встречу и готовиться к ней
Что в офисе, что на удаленке нас часто преследуют бестолковые встречи, которые несут больше трату времени, чем конкретную пользу.
Хотелось бы рассмотреть пару простых приемов, которые можно применить при назначении встреч/созвонов, чтобы выжать из них побольше пользы и не прослыть мудаком.
Тщательно опишите тему встречи со всем сопутствующим контекстом
Если вы это сделаете, то каждый приглашенный будет заранее понимать, о чем предстоит говорить, подготовится к разговору, соберет необходимые данные и ваше собрание пройдет в продуктивном обсуждении. Если же тему встречи описать недостаточно подробно, то вы будете тратить время кучи людей, объясняя, про что же вы хотели на самом деле поговорить. Потом выяснится, что ряду людей нужно уточнить какие-нибудь факты или просто хорошенько подумать. В итоге вы потратите N человекочасов, но назначите еще одну встречу, на которую люди придут уже подготовившись (подготовившись к разговору и к тому, что вы так себе работник).
Плохо:
- Коллеги, надо встретиться обсудить проект.
- Доброго времени суток! У нас проблема.
- Смотрите, какой я занятой, думайте, что я очень эффективный. Короче, надо встретиться, по задачке обкашлять вопросики.
Хорошо:
- Необходимо обсудить интеграцию со сторонней системой X нашего решения Z. Вводные данные и стартовое ТЗ лежат тут, надо будет обговорить детали реализации обмена данными (протокол, формат и защиту данных).
- Встреча насчет обновления нашей платформы. Накидаем общий план как будем делать, какие команды понадобится привлечь, договоримся, кто и когда конкретно этим займется.
- Ребята, у нас проблема с заведением нового контрагента в системе. Делаю так-то и так-то, получаю вот такую ошибку (ссылка на скриншот или видеозапись). Ошибка замечена сегодня в районе обеда.
Хорошо подумайте, каких людей звать на встречу
Типичная проблема бездумного менеджмента – звать на встречу как можно больше людей. «Одна голова хорошо, а восемь лучше», «там разберемся, кто понадобится», «да ладно, мы же команда, пусть все 25 приходят, обсудим».
Конечно, если вы хотите пробудить ярость, потратить много человекочасов (и денег компании), прослыть бестолковым, то назначайте встречу на всех, кого смогли вспомнить по этому проекту.
Если же хотите сделать нормально, подумайте о том, кто конкретно вам понадобится и зачем. Это лучше всего решать, пока вы будете формулировать подробную повестку для встречи, там и нужное осознание придет.
Хорошо готовьтесь к встрече сами
Если на встрече будет нужна какая-то вводная информация от вас, приготовьте всё заранее, не заставляйте несколько человек сидеть и ждать, пока вы разберетесь и сформулируете нормально (а еще попробуй сформулируй хорошо на ходу).
Итог
Уважайте время и нервы своих коллег, подходите к своей работе профессионально.
Что в офисе, что на удаленке нас часто преследуют бестолковые встречи, которые несут больше трату времени, чем конкретную пользу.
Хотелось бы рассмотреть пару простых приемов, которые можно применить при назначении встреч/созвонов, чтобы выжать из них побольше пользы и не прослыть мудаком.
Тщательно опишите тему встречи со всем сопутствующим контекстом
Если вы это сделаете, то каждый приглашенный будет заранее понимать, о чем предстоит говорить, подготовится к разговору, соберет необходимые данные и ваше собрание пройдет в продуктивном обсуждении. Если же тему встречи описать недостаточно подробно, то вы будете тратить время кучи людей, объясняя, про что же вы хотели на самом деле поговорить. Потом выяснится, что ряду людей нужно уточнить какие-нибудь факты или просто хорошенько подумать. В итоге вы потратите N человекочасов, но назначите еще одну встречу, на которую люди придут уже подготовившись (подготовившись к разговору и к тому, что вы так себе работник).
Плохо:
- Коллеги, надо встретиться обсудить проект.
- Доброго времени суток! У нас проблема.
- Смотрите, какой я занятой, думайте, что я очень эффективный. Короче, надо встретиться, по задачке обкашлять вопросики.
Хорошо:
- Необходимо обсудить интеграцию со сторонней системой X нашего решения Z. Вводные данные и стартовое ТЗ лежат тут, надо будет обговорить детали реализации обмена данными (протокол, формат и защиту данных).
- Встреча насчет обновления нашей платформы. Накидаем общий план как будем делать, какие команды понадобится привлечь, договоримся, кто и когда конкретно этим займется.
- Ребята, у нас проблема с заведением нового контрагента в системе. Делаю так-то и так-то, получаю вот такую ошибку (ссылка на скриншот или видеозапись). Ошибка замечена сегодня в районе обеда.
Хорошо подумайте, каких людей звать на встречу
Типичная проблема бездумного менеджмента – звать на встречу как можно больше людей. «Одна голова хорошо, а восемь лучше», «там разберемся, кто понадобится», «да ладно, мы же команда, пусть все 25 приходят, обсудим».
Конечно, если вы хотите пробудить ярость, потратить много человекочасов (и денег компании), прослыть бестолковым, то назначайте встречу на всех, кого смогли вспомнить по этому проекту.
Если же хотите сделать нормально, подумайте о том, кто конкретно вам понадобится и зачем. Это лучше всего решать, пока вы будете формулировать подробную повестку для встречи, там и нужное осознание придет.
Хорошо готовьтесь к встрече сами
Если на встрече будет нужна какая-то вводная информация от вас, приготовьте всё заранее, не заставляйте несколько человек сидеть и ждать, пока вы разберетесь и сформулируете нормально (а еще попробуй сформулируй хорошо на ходу).
Итог
Уважайте время и нервы своих коллег, подходите к своей работе профессионально.
Т.к. некоторые посты у меня выходят неоднозначные, и потом читатели приходят в личку их пообсуждать, то я сделал чат для этого канала, куда вы можете зайти и подискутировать, или накинуть тем для следующих постов. https://news.1rj.ru/str/general_it_talks_chat
Telegram
Чат канала Тимлид Очевидность
Чат канала https://news.1rj.ru/str/general_it_talks
Админ и автор @eantonov
Админ и автор @eantonov
Получение информации, осмысление, применение
Хочется вкратце проговорить то, как учиться, чтобы научиться, а не потратить время зря.
Сразу отмечу, что идея не моя, но дошел я до нее в последние годы самостоятельно. К тому же на днях прочитал её у Максима Дорофеева в книге «Путь джедая», а он это тянет из буддизма и научных исследований.
Идея очевидная (хотя не так часто применяемая), а значит, ей самое место в моем канале 😁
3 этапа обучения
Получение информации
Это самое легкое и понятное. Прочитал книжку, посмотрел видеоурок, сходил на курс.
До этого этапа доходят все.
Осмысление информации
Тут уже сложнее. Зачастую кажется, что раз мы книжку прочитали, то мы уже всё знаем и надо читать новую. Однако прочитать и понять, осмыслить – не одно и то же.
Лично я какие-то ёмкие книги стараюсь читать медленно. Прочитал главу-две, сделал конспекты, обдумал саму теорию, прикинул, как можно переложить на практику, представил, как будешь действовать в конкретном своём случае и т. д.
Если слишком быстро прочитать книгу без рефлексии, то есть риск запомнить только последние несколько глав, а остальное пролетит мимо.
До этого этапа доходят уже не все.
Применение на практике
Тут еще сложнее.
Во-первых, есть много теоретиков (вы таких точно знаете), которые читали и «знают» про всё на свете, однако по факту ничего не сделали на практике, результатов никаких показать не могут и вообще «Что ты ко мне с этой практикой лезешь?! Я слишком хорош, чтобы руки марать!»
Во-вторых, много таких, которые пропускают получение и осознание теории, а сразу начинают неправильно делать что-то руками.
Привет программистам, сначала пишущим костыли, а потом читающим документацию, где написано, как нужно было делать.
Этот этап тоже оказывается достижим не всеми.
Итог
Не торопитесь (если нет объективных важных для этого причин), получайте информацию в разумных порциях, обязательно её хорошенько осмысливайте, и не забывайте подкреплять полученные знания на практике.
Хочется вкратце проговорить то, как учиться, чтобы научиться, а не потратить время зря.
Сразу отмечу, что идея не моя, но дошел я до нее в последние годы самостоятельно. К тому же на днях прочитал её у Максима Дорофеева в книге «Путь джедая», а он это тянет из буддизма и научных исследований.
Идея очевидная (хотя не так часто применяемая), а значит, ей самое место в моем канале 😁
3 этапа обучения
Получение информации
Это самое легкое и понятное. Прочитал книжку, посмотрел видеоурок, сходил на курс.
До этого этапа доходят все.
Осмысление информации
Тут уже сложнее. Зачастую кажется, что раз мы книжку прочитали, то мы уже всё знаем и надо читать новую. Однако прочитать и понять, осмыслить – не одно и то же.
Лично я какие-то ёмкие книги стараюсь читать медленно. Прочитал главу-две, сделал конспекты, обдумал саму теорию, прикинул, как можно переложить на практику, представил, как будешь действовать в конкретном своём случае и т. д.
Если слишком быстро прочитать книгу без рефлексии, то есть риск запомнить только последние несколько глав, а остальное пролетит мимо.
До этого этапа доходят уже не все.
Применение на практике
Тут еще сложнее.
Во-первых, есть много теоретиков (вы таких точно знаете), которые читали и «знают» про всё на свете, однако по факту ничего не сделали на практике, результатов никаких показать не могут и вообще «Что ты ко мне с этой практикой лезешь?! Я слишком хорош, чтобы руки марать!»
Во-вторых, много таких, которые пропускают получение и осознание теории, а сразу начинают неправильно делать что-то руками.
Привет программистам, сначала пишущим костыли, а потом читающим документацию, где написано, как нужно было делать.
Этот этап тоже оказывается достижим не всеми.
Итог
Не торопитесь (если нет объективных важных для этого причин), получайте информацию в разумных порциях, обязательно её хорошенько осмысливайте, и не забывайте подкреплять полученные знания на практике.
👍2
Овертаймы
Сегодня хочу поговорить про очевидные, но часто игнорируемые идеи вокруг овертаймов.
Овертаймы подрывают ваше здоровье
Это мысль простая и понятная. Больше овертаймов, больше стрессов, нервного напряжения, меньше сна и отдыха.
Как-то на нервах и овертаймах я потерял чувство вкуса на три месяца. Когда напряженный период кончился, вкус постепенно вернулся.
В другой раз я работал 3-4 месяца по 260-280 часов в месяц и это тоже подорвало мое здоровье и в целом восприятие работы.
Не повторяйте таких ошибок, не думайте: «со мной точно такого не случится», не надейтесь, что пронесет. Берегите себя.
Овертаймы ускоряют сейчас, но замедляют потом
Да, сейчас вы посидели до ночи, или на выходных и сделали свою работу до дедлайна. Помните, что это работает только в оооочень краткосрочной перспективе. Если вы будете делать так регулярно, вы начнете работать дольше, а делать меньше, соображать хуже. Может дойти и до совсем фиговых состояний, когда работать не захочется, да уже и физически не потянете.
Лучше подберите свой темп так, чтобы вы могли в нем бесконечно долго работать, при этом успевая отдыхать, уделять время личным делам. Тогда и в долгосрочной перспективе вы сделаете больше, а удовольствие от работы и жизни в целом вы будете получать дольше.
Овертаймы не всегда нужны
Если к вам прибегает менеджер и кричит: «СРОЧНО! ASAP! НАДО СЕГОДНЯ!» - хорошенько задумайтесь, может, оно и не нужно. Всем известен этот механизм: прилетаешь, громче всех кричишь, нагоняешь страху и тогда твою задачу возьмут первой и сделают быстрее. Не будьте такими менеджерами и не идите у них на поводу.
Наблюдайте за людьми, раздающими вам задачи, и вы поймете, на кого как реагировать. Ну и не забывайте задавать вопросы «если я сегодня не успею, то что будет?».
Не хвалитесь овертаймами
Очень распространенная проблема, когда в коллективе есть 1-2-N человек, которые овертаймят и трубят об этом на каждом шагу. Для меня это выглядит как «мама, папа, учительница, посмотрите, как я много сидел над уроками, похвалите меня!». Это может стать проблемой по следующим причинам:
- Сегодня – рекорд, завтра - норма. Если менеджер у вас не самый хороший, то сегодня вы хвалитесь овертаймами, а завтра этого он ждет от вас, как норму. А послезавтра он ждет от ваших коллег такую же норму. Поздравляю, вы сделали жизнь и работу хуже всем своим коллегам, пытаясь выпросить похвалу.
- Происходит неправильное рассмотрение ценности работы сотрудника. Начинает складываться впечатление, что нытик, который «больше всех устал», работает лучше всех. Однако зачастую это как раз наоборот. Кто плохо работает, не может организовать нормально свою работу – овертаймит, делает работу дольше, хуже, допускает больше ошибок. Кто может организовать свою работу эффективно, сделает свои дела вовремя и пойдет домой отдыхать. И вот в командах, где много беспорядка, бестолковости, хаоса складывается мнение, что кто вовремя пошел домой, тот лодырь и плохой работник, а кто сидит до ночи – герой, молодец и вообще золотой человек.
Итог
Берегите своё здоровье. Планируйте и делайте свою работу эффективно. Применяйте овертаймы очень осторожно, когда без этого действительно нельзя, не вводите это в регулярную практику. Не хвалитесь тем, как вы много работали и как вы устали. Если хочется похвалиться, похвалитесь результатами своей работы – это настоящая ценность вашего труда, а не ваша усталость от него.
Сегодня хочу поговорить про очевидные, но часто игнорируемые идеи вокруг овертаймов.
Овертаймы подрывают ваше здоровье
Это мысль простая и понятная. Больше овертаймов, больше стрессов, нервного напряжения, меньше сна и отдыха.
Как-то на нервах и овертаймах я потерял чувство вкуса на три месяца. Когда напряженный период кончился, вкус постепенно вернулся.
В другой раз я работал 3-4 месяца по 260-280 часов в месяц и это тоже подорвало мое здоровье и в целом восприятие работы.
Не повторяйте таких ошибок, не думайте: «со мной точно такого не случится», не надейтесь, что пронесет. Берегите себя.
Овертаймы ускоряют сейчас, но замедляют потом
Да, сейчас вы посидели до ночи, или на выходных и сделали свою работу до дедлайна. Помните, что это работает только в оооочень краткосрочной перспективе. Если вы будете делать так регулярно, вы начнете работать дольше, а делать меньше, соображать хуже. Может дойти и до совсем фиговых состояний, когда работать не захочется, да уже и физически не потянете.
Лучше подберите свой темп так, чтобы вы могли в нем бесконечно долго работать, при этом успевая отдыхать, уделять время личным делам. Тогда и в долгосрочной перспективе вы сделаете больше, а удовольствие от работы и жизни в целом вы будете получать дольше.
Овертаймы не всегда нужны
Если к вам прибегает менеджер и кричит: «СРОЧНО! ASAP! НАДО СЕГОДНЯ!» - хорошенько задумайтесь, может, оно и не нужно. Всем известен этот механизм: прилетаешь, громче всех кричишь, нагоняешь страху и тогда твою задачу возьмут первой и сделают быстрее. Не будьте такими менеджерами и не идите у них на поводу.
Наблюдайте за людьми, раздающими вам задачи, и вы поймете, на кого как реагировать. Ну и не забывайте задавать вопросы «если я сегодня не успею, то что будет?».
Не хвалитесь овертаймами
Очень распространенная проблема, когда в коллективе есть 1-2-N человек, которые овертаймят и трубят об этом на каждом шагу. Для меня это выглядит как «мама, папа, учительница, посмотрите, как я много сидел над уроками, похвалите меня!». Это может стать проблемой по следующим причинам:
- Сегодня – рекорд, завтра - норма. Если менеджер у вас не самый хороший, то сегодня вы хвалитесь овертаймами, а завтра этого он ждет от вас, как норму. А послезавтра он ждет от ваших коллег такую же норму. Поздравляю, вы сделали жизнь и работу хуже всем своим коллегам, пытаясь выпросить похвалу.
- Происходит неправильное рассмотрение ценности работы сотрудника. Начинает складываться впечатление, что нытик, который «больше всех устал», работает лучше всех. Однако зачастую это как раз наоборот. Кто плохо работает, не может организовать нормально свою работу – овертаймит, делает работу дольше, хуже, допускает больше ошибок. Кто может организовать свою работу эффективно, сделает свои дела вовремя и пойдет домой отдыхать. И вот в командах, где много беспорядка, бестолковости, хаоса складывается мнение, что кто вовремя пошел домой, тот лодырь и плохой работник, а кто сидит до ночи – герой, молодец и вообще золотой человек.
Итог
Берегите своё здоровье. Планируйте и делайте свою работу эффективно. Применяйте овертаймы очень осторожно, когда без этого действительно нельзя, не вводите это в регулярную практику. Не хвалитесь тем, как вы много работали и как вы устали. Если хочется похвалиться, похвалитесь результатами своей работы – это настоящая ценность вашего труда, а не ваша усталость от него.
Покажите менеджеру факты/деньги/профит
Меня периодически спрашивают: «А как вы берете в работу техдолг? Нам вот менеджер запрещает, говорит, это денег не приносит» или «А как вы пишете тесты? Нам менеджер запрещает, говорит, фичи пилить надо» и т. д.
В оптимистичном и реалистичном случае менеджера можно понять и с ним можно договориться. Большинство проблем такого плана решается разговором на языке, понятном собеседнику.
В пессимистичном случае встречаются непробиваемые люди, которые стоят на своём ПРОСТО ПОТОМУ ЧТО. В глубине души я думаю, что, имея выдающиеся навыки переговорщика, и с такими людьми можно договориться, но это отдельное сложное искусство. Так что для себя я примерно определил границы того, где можно бороться, прикладывать усилия, время, душевные силы, а когда проще и выгоднее сказать: «Ну тут мои полномочия всё, окончены» и двинуться дальше. Ибо бороться надо за что-то перспективное и стоящее, а не просто потому что ЭТО ЖЕ ВЫЗОВ.
Как не надо
Часто аргументация инженеров идет на сугубо техническом уровне. В ход идет непонятное менеджеру: бест практисес программирования, чистый код, ТЕХНИЧЕСКИЙ ДОЛГ (что и кому он должен – ЭТО ЖЕ ОЧЕВИДНО!!!), хайповые слова (привет k8s). По результатам этих разговоров менеджер думает, что вы или лапшу на уши вешаете, желая просто в резюме галочек проставить, либо просто хотите поиграть с новыми красивыми игрушками за счет бизнеса (кстати, иногда так и есть).
Как надо
Мой совет: поймите мотивацию вашего менеджера (в основном это деньги, или штуки, конвертируемые в деньги: скорость выпуска фичей, трудозатраты, количество работников и т. д.) и стройте разговор, который подсветит нужные ему, а не вам аргументы и факты.
Не нравится менеджеру ваше желание гасить технический долг? Объясните ему, что, не погасив его сейчас, следующие фичи вы будете делать дольше (деньги), проект будет работать менее стабильно (деньги), команда будет более демотивирована из года в год лопатить это неудобно поддерживаемое легаси и возможно частично разбежится (деньги). Такое объяснение работает лучше и понятнее.
Тут хотел бы сделать оговорку, что когда вы понимаете этот язык менеджмента, то можно дойти до ложных манипуляций, жонглируя фактами так, как у годно вам, чтобы надуть менеджера, который не очень-то технически компетентен. Я так делать вам не рекомендую, потому что ваша репутация (которая будет с вами не только в этой компании) важнее сиюминутных продавливаний своих хотелок. А если вы менеджер, запаситесь толковым тимлидом, которому вы доверяете, и который будет отсеивать таких недобросовестных врунишек.
Иногда бывают случаи, когда менеджер говорит: «Ой, да ладно, ты драматизируешь». В этом случае всё работает как с воспитанием маленьких детей. Если 100 раз повторять, что нельзя горячую кастрюльку трогать, то ребенок не перестанет хотеть её потрогать. А стоит дать ему один раз обжечься (я не специалист в воспитании, не повторяйте это дома), то ему насовсем расхочется это делать. Так и здесь: дайте человеку увидеть результаты его попустительства и потом вернитесь к этому разговору еще раз.
Итог
Рецепт решения очень большого количества проблем – откровенный и без страха разговор на языке, понятном собеседнику. Не стесняйтесь разговаривать.
Меня периодически спрашивают: «А как вы берете в работу техдолг? Нам вот менеджер запрещает, говорит, это денег не приносит» или «А как вы пишете тесты? Нам менеджер запрещает, говорит, фичи пилить надо» и т. д.
В оптимистичном и реалистичном случае менеджера можно понять и с ним можно договориться. Большинство проблем такого плана решается разговором на языке, понятном собеседнику.
В пессимистичном случае встречаются непробиваемые люди, которые стоят на своём ПРОСТО ПОТОМУ ЧТО. В глубине души я думаю, что, имея выдающиеся навыки переговорщика, и с такими людьми можно договориться, но это отдельное сложное искусство. Так что для себя я примерно определил границы того, где можно бороться, прикладывать усилия, время, душевные силы, а когда проще и выгоднее сказать: «Ну тут мои полномочия всё, окончены» и двинуться дальше. Ибо бороться надо за что-то перспективное и стоящее, а не просто потому что ЭТО ЖЕ ВЫЗОВ.
Как не надо
Часто аргументация инженеров идет на сугубо техническом уровне. В ход идет непонятное менеджеру: бест практисес программирования, чистый код, ТЕХНИЧЕСКИЙ ДОЛГ (что и кому он должен – ЭТО ЖЕ ОЧЕВИДНО!!!), хайповые слова (привет k8s). По результатам этих разговоров менеджер думает, что вы или лапшу на уши вешаете, желая просто в резюме галочек проставить, либо просто хотите поиграть с новыми красивыми игрушками за счет бизнеса (кстати, иногда так и есть).
Как надо
Мой совет: поймите мотивацию вашего менеджера (в основном это деньги, или штуки, конвертируемые в деньги: скорость выпуска фичей, трудозатраты, количество работников и т. д.) и стройте разговор, который подсветит нужные ему, а не вам аргументы и факты.
Не нравится менеджеру ваше желание гасить технический долг? Объясните ему, что, не погасив его сейчас, следующие фичи вы будете делать дольше (деньги), проект будет работать менее стабильно (деньги), команда будет более демотивирована из года в год лопатить это неудобно поддерживаемое легаси и возможно частично разбежится (деньги). Такое объяснение работает лучше и понятнее.
Тут хотел бы сделать оговорку, что когда вы понимаете этот язык менеджмента, то можно дойти до ложных манипуляций, жонглируя фактами так, как у годно вам, чтобы надуть менеджера, который не очень-то технически компетентен. Я так делать вам не рекомендую, потому что ваша репутация (которая будет с вами не только в этой компании) важнее сиюминутных продавливаний своих хотелок. А если вы менеджер, запаситесь толковым тимлидом, которому вы доверяете, и который будет отсеивать таких недобросовестных врунишек.
Иногда бывают случаи, когда менеджер говорит: «Ой, да ладно, ты драматизируешь». В этом случае всё работает как с воспитанием маленьких детей. Если 100 раз повторять, что нельзя горячую кастрюльку трогать, то ребенок не перестанет хотеть её потрогать. А стоит дать ему один раз обжечься (я не специалист в воспитании, не повторяйте это дома), то ему насовсем расхочется это делать. Так и здесь: дайте человеку увидеть результаты его попустительства и потом вернитесь к этому разговору еще раз.
Итог
Рецепт решения очень большого количества проблем – откровенный и без страха разговор на языке, понятном собеседнику. Не стесняйтесь разговаривать.
Декомпозиция и регулярность
Проблема
Часто люди сталкиваются с проблемой неспособности приступить к большим задачам. Когда задача очень большая и по ней нужно проделать очень много работ, то мы делаем всё, что только возможно, кроме самой этой задачи.
Надо пилить огромную фичу, а мы думаем: «Не, лучше я сейчас маленькие все сделаю, чтобы не отвлекали, а потом за большую кааааак примусь». Или надо готовить презентацию, а мы говорим себе: «Вот сначала домашние дела все сделаю, а потом уже спокойненько подготовлюсь к докладу». В итоге, конечно же, мы большую часть времени занимаемся левыми задачами, никак не приближающими нас к цели, а потом в огне доделываем основную задачу абы как за какой-то минимум времени.
Существуют различные объяснения этого механизма, но их знание зачастую не очень-то помогает начинать большие дела сразу, не откладывая.
Тут я хотел бы поделиться кэпским способом того, как я борюсь с этим на практике.
Декомпозиция
Первое, что я делаю – это декомпозиция на оооочень небольшие части. Когда задача разбита на маленькие кусочки, то психологически намного легче начать её делать, потому что фактически ты приступаешь не к огромному делу, которому не видно конца и края, а к небольшой задаче.
Например, я захотел подготовиться к ведению коллективного твиттера. Разбил работу на десяток задач: договориться с организаторами, составить план, написать контент под каждый день, вычитать контент, подготовить свой профиль.
Точно так же и в программировании, спорте, путешествиях, изучении любых новых навыков. Конечная цель, конечно, быть должна, но каждый день я стараюсь думать не о всём объеме работы, ведущем к этой цели, а конкретном маленьком шажке, который сейчас необходимо сделать.
Постоянство
Так как работу я разбиваю на маленькие шажки, то для реализации общей задачи их надо выполнить очень много. Я пробовал делать это героическими наскоками, типа вот я в будни ничего не делаю, а на выходных сажусь и сразу 15 маленьких задач закрываю. Может, у кого-то такой подход работает. У меня – точно нет.
Для меня работает дисциплина и регулярность. Мне проще ежедневно делать по 1-2 маленьких шага, чем выбрать определенный день и потратить его целиком на одно дело. Для меня в этом случае теряется профит от декомпозиции. Ведь если всё делать в один день, то я хоть и думаю об одном шаге, но знаю, что через полчаса будет другой, а за ним – еще другой и т. д. А когда по маленькому кусочку в день, то я ненапряжно выполнил его и забыл до завтра. А завтра проснулся, «ОБНУЛИЛСЯ» и снова могу делать маленький шаг, совершенно не уставая.
Итог
Не бойтесь делать большие дела, не прокрастинируйте, не бегите от проблем. Подберите комфортный вам способ и темп работы, и всё получится!
Проблема
Часто люди сталкиваются с проблемой неспособности приступить к большим задачам. Когда задача очень большая и по ней нужно проделать очень много работ, то мы делаем всё, что только возможно, кроме самой этой задачи.
Надо пилить огромную фичу, а мы думаем: «Не, лучше я сейчас маленькие все сделаю, чтобы не отвлекали, а потом за большую кааааак примусь». Или надо готовить презентацию, а мы говорим себе: «Вот сначала домашние дела все сделаю, а потом уже спокойненько подготовлюсь к докладу». В итоге, конечно же, мы большую часть времени занимаемся левыми задачами, никак не приближающими нас к цели, а потом в огне доделываем основную задачу абы как за какой-то минимум времени.
Существуют различные объяснения этого механизма, но их знание зачастую не очень-то помогает начинать большие дела сразу, не откладывая.
Тут я хотел бы поделиться кэпским способом того, как я борюсь с этим на практике.
Декомпозиция
Первое, что я делаю – это декомпозиция на оооочень небольшие части. Когда задача разбита на маленькие кусочки, то психологически намного легче начать её делать, потому что фактически ты приступаешь не к огромному делу, которому не видно конца и края, а к небольшой задаче.
Например, я захотел подготовиться к ведению коллективного твиттера. Разбил работу на десяток задач: договориться с организаторами, составить план, написать контент под каждый день, вычитать контент, подготовить свой профиль.
Точно так же и в программировании, спорте, путешествиях, изучении любых новых навыков. Конечная цель, конечно, быть должна, но каждый день я стараюсь думать не о всём объеме работы, ведущем к этой цели, а конкретном маленьком шажке, который сейчас необходимо сделать.
Постоянство
Так как работу я разбиваю на маленькие шажки, то для реализации общей задачи их надо выполнить очень много. Я пробовал делать это героическими наскоками, типа вот я в будни ничего не делаю, а на выходных сажусь и сразу 15 маленьких задач закрываю. Может, у кого-то такой подход работает. У меня – точно нет.
Для меня работает дисциплина и регулярность. Мне проще ежедневно делать по 1-2 маленьких шага, чем выбрать определенный день и потратить его целиком на одно дело. Для меня в этом случае теряется профит от декомпозиции. Ведь если всё делать в один день, то я хоть и думаю об одном шаге, но знаю, что через полчаса будет другой, а за ним – еще другой и т. д. А когда по маленькому кусочку в день, то я ненапряжно выполнил его и забыл до завтра. А завтра проснулся, «ОБНУЛИЛСЯ» и снова могу делать маленький шаг, совершенно не уставая.
Итог
Не бойтесь делать большие дела, не прокрастинируйте, не бегите от проблем. Подберите комфортный вам способ и темп работы, и всё получится!
Веду (пишу как всегда очевидные вещи) на этой неделе коллективный аккаунт Руководитель разработки https://twitter.com/leadunderhood
Приходите пообщаться👍
Приходите пообщаться👍
А не мудак ли я?
Полгода назад увидел на столе у коллеги книгу «Как разговаривать с мудаками» и посмеялся.
Месяц назад жена начала её читать, я стал смеяться уже меньше.
Пару недель назад я тоже стал её читать и совсем перестало быть смешно.
Почему перестало? Потому что в некоторых мудацких примерах я начал явно узнавать себя.
Я начал думать, а как же человеку узнать, не мудак ли он? Сравнил с какими-то действиями, которые я делал интуитивно и накидал небольшой план.
Шаг №1: Рефлексия
Твердо уверен, что без регулярной рефлексии никуда. Не надо ждать, пока внезапно придет некое озарение и ты такой: «О! Так я ж как мудак себя веду!». Обычно мудаки в фоновом режиме постоянно уверены, что они не такие. И только регулярное сознательное самосозерцание с обдумыванием своих реакций, поступков и последствий может всколыхнуть их уверенность в своей непогрешимости.
Как пример: задумайтесь, если вы привыкли жить в парадигме «все вокруг дураки, из-за них мои проблемы, а я молодец и невинная жертва обстоятельств», то возможно вам надо хорошенько подумать о себе и своих поступках.
Шаг №2: Обратная связь
Неважно, работа это или личные отношения – не стесняйтесь открыто попросить фидбэк о себе и своем поведении.
Тут главное дать понять человеку, что ни в коем случае не обидитесь на него, если он вам что-то негативное скажет о ваших поступках. Конструктивная критика - всегда замечательно. На мой взгляд, это куда полезнее, чем всегда одинаковые любезности из серии «да вроде всё норм».
Шаг №3: Мой личный
Это моё личное решение. Оно не для диагностики, а скорее для того, чтобы не дать себе сильно скатываться в мудизм.
«Никогда не требуй от других того, что не соблюдаешь сам». Таков мой принцип, и я не уверен, но надеюсь, что он не дает мне сильно перегибать палку в любых отношениях, как рабочих, так и личных.
Итог
Не стесняйтесь откровенно разговаривать, прояснять сомнительные ситуации. Не бойтесь негативного фидбэка. Можете даже порадоваться ему, ведь осознание проблемы – первый шаг к её решению
Полгода назад увидел на столе у коллеги книгу «Как разговаривать с мудаками» и посмеялся.
Месяц назад жена начала её читать, я стал смеяться уже меньше.
Пару недель назад я тоже стал её читать и совсем перестало быть смешно.
Почему перестало? Потому что в некоторых мудацких примерах я начал явно узнавать себя.
Я начал думать, а как же человеку узнать, не мудак ли он? Сравнил с какими-то действиями, которые я делал интуитивно и накидал небольшой план.
Шаг №1: Рефлексия
Твердо уверен, что без регулярной рефлексии никуда. Не надо ждать, пока внезапно придет некое озарение и ты такой: «О! Так я ж как мудак себя веду!». Обычно мудаки в фоновом режиме постоянно уверены, что они не такие. И только регулярное сознательное самосозерцание с обдумыванием своих реакций, поступков и последствий может всколыхнуть их уверенность в своей непогрешимости.
Как пример: задумайтесь, если вы привыкли жить в парадигме «все вокруг дураки, из-за них мои проблемы, а я молодец и невинная жертва обстоятельств», то возможно вам надо хорошенько подумать о себе и своих поступках.
Шаг №2: Обратная связь
Неважно, работа это или личные отношения – не стесняйтесь открыто попросить фидбэк о себе и своем поведении.
Тут главное дать понять человеку, что ни в коем случае не обидитесь на него, если он вам что-то негативное скажет о ваших поступках. Конструктивная критика - всегда замечательно. На мой взгляд, это куда полезнее, чем всегда одинаковые любезности из серии «да вроде всё норм».
Шаг №3: Мой личный
Это моё личное решение. Оно не для диагностики, а скорее для того, чтобы не дать себе сильно скатываться в мудизм.
«Никогда не требуй от других того, что не соблюдаешь сам». Таков мой принцип, и я не уверен, но надеюсь, что он не дает мне сильно перегибать палку в любых отношениях, как рабочих, так и личных.
Итог
Не стесняйтесь откровенно разговаривать, прояснять сомнительные ситуации. Не бойтесь негативного фидбэка. Можете даже порадоваться ему, ведь осознание проблемы – первый шаг к её решению
Менеджер, который кричал «СРОЧНО!»
Думаю, практически каждый знаком со сказкой, в которой мальчик врал и кричал «волки!» много раз, хотя волки не нападали. А потом, когда они напали, ему никто не поверил, и парень погиб из-за своего вранья.
А теперь переносимся в разработку и вспоминаем менеджеров/заказчиков, которые на каждую задачу кричат «СРОЧНО! ASAP!».
Зачем они это делают? В большинстве случаев, чтобы их задачу побыстрее взяли в работу. Т. е. задача на самом деле не горит, но он «на всякий случай» искусственно завышает ей приоритет, в результате чего все задачи от него – якобы горящие, надо всё бросать и выполнять.
В долгосрочной перспективе это не работает
Можно завысить приоритет 1-2-10 раз и это сработает, твою задачу сделают пораньше. Но после реализации будет и самим исполнителям понятно, что по факту она не горела, ими просто манипулировали. Из этого исполнитель может сделать два вывода:
1. Менеджер мудак (врет, плохо организовал, безалаберный).
2. Впредь приоритет таких задач можно занижать.
В итоге менеджер и профессиональный образ себе подпортил, и добился противоположного эффекта по срочности выполнения его задач. Теперь они в пыльном углу, потому что «да блин, там, наверное, как всегда».
Можно возмутиться «Так ведь заказчик всегда прав! Говорит бросать и делать, значит надо бросать и делать!». Справедливое возмущение, если у вас один заказчик на одну команду, но чаще встречаются ситуации, когда команда одна, а заказчиков много и приходится выбирать, чьи задачи делать раньше. Тут-то врунишка и будет задвинут подальше.
А если и правда срочно?
Порой я тоже выступаю заказчиком для команд, у которых так же много заказчиков. Иногда бывает нужно действительно что-то горящее.
Я точно знаю, что я не вру, но ребята могут и сомневаться (их право). Поэтому, при постановке срочных задач, я уточняю немного контекста, чтобы объяснить, почему именно они горят.
Не прям отчет с обоснованием, но достаточно контекста, чтобы исполнитель понял, что задача реально срочная и я поставил ей правильный приоритет.
А если и правда ВСЁ СРОЧНО?
Если у менеджера и правда каждая задача горит, сроки поджимают, надо позавчера, то у меня два варианта:
1.У него сложная работа в очень нагруженном темпе и какой-то сложной сфере. Ему надо помогать.
2.Он просто раздолбай и чайка. Надо бы задуматься о том, как ведутся дела, как организуется работа, как генерятся задачи и т. д. А может, и задуматься о профпригодности такого работника.
Конечно, каждый из варианта №2 будет вам рассказывать, как ему тяжело и трудно, и что он на самом деле из варианта №1.
Рассказывать можно что угодно, а по конкретным фактам люди уже давно разобрались, кто тяжело работает, а кто имитирует бурную деятельность.
Итог
Не надо обманывать и думать, что на каждую задачу добавлять ASAP – это хитрая стратегия. Берегите свою карму, уважайте чужой труд и время.
Думаю, практически каждый знаком со сказкой, в которой мальчик врал и кричал «волки!» много раз, хотя волки не нападали. А потом, когда они напали, ему никто не поверил, и парень погиб из-за своего вранья.
А теперь переносимся в разработку и вспоминаем менеджеров/заказчиков, которые на каждую задачу кричат «СРОЧНО! ASAP!».
Зачем они это делают? В большинстве случаев, чтобы их задачу побыстрее взяли в работу. Т. е. задача на самом деле не горит, но он «на всякий случай» искусственно завышает ей приоритет, в результате чего все задачи от него – якобы горящие, надо всё бросать и выполнять.
В долгосрочной перспективе это не работает
Можно завысить приоритет 1-2-10 раз и это сработает, твою задачу сделают пораньше. Но после реализации будет и самим исполнителям понятно, что по факту она не горела, ими просто манипулировали. Из этого исполнитель может сделать два вывода:
1. Менеджер мудак (врет, плохо организовал, безалаберный).
2. Впредь приоритет таких задач можно занижать.
В итоге менеджер и профессиональный образ себе подпортил, и добился противоположного эффекта по срочности выполнения его задач. Теперь они в пыльном углу, потому что «да блин, там, наверное, как всегда».
Можно возмутиться «Так ведь заказчик всегда прав! Говорит бросать и делать, значит надо бросать и делать!». Справедливое возмущение, если у вас один заказчик на одну команду, но чаще встречаются ситуации, когда команда одна, а заказчиков много и приходится выбирать, чьи задачи делать раньше. Тут-то врунишка и будет задвинут подальше.
А если и правда срочно?
Порой я тоже выступаю заказчиком для команд, у которых так же много заказчиков. Иногда бывает нужно действительно что-то горящее.
Я точно знаю, что я не вру, но ребята могут и сомневаться (их право). Поэтому, при постановке срочных задач, я уточняю немного контекста, чтобы объяснить, почему именно они горят.
Не прям отчет с обоснованием, но достаточно контекста, чтобы исполнитель понял, что задача реально срочная и я поставил ей правильный приоритет.
А если и правда ВСЁ СРОЧНО?
Если у менеджера и правда каждая задача горит, сроки поджимают, надо позавчера, то у меня два варианта:
1.У него сложная работа в очень нагруженном темпе и какой-то сложной сфере. Ему надо помогать.
2.Он просто раздолбай и чайка. Надо бы задуматься о том, как ведутся дела, как организуется работа, как генерятся задачи и т. д. А может, и задуматься о профпригодности такого работника.
Конечно, каждый из варианта №2 будет вам рассказывать, как ему тяжело и трудно, и что он на самом деле из варианта №1.
Рассказывать можно что угодно, а по конкретным фактам люди уже давно разобрались, кто тяжело работает, а кто имитирует бурную деятельность.
Итог
Не надо обманывать и думать, что на каждую задачу добавлять ASAP – это хитрая стратегия. Берегите свою карму, уважайте чужой труд и время.
Теория разбитых окон
Существует криминологическая теория, которая утверждает, что попустительство общества к мелким правонарушениям, таким как выбрасывание мусора в неустановленных для этого местах, вандализм, публичное пьянство, прыжки через турникеты в метро и прочие, непосредственно провоцирует людей на совершение аналогичных или более серьёзных правонарушений.
Психологический механизм такой провокации на бытовом уровне иллюстрируется следующей фразой: «Если другим можно, то почему нельзя мне?». Человек видит, что нарушения правил поведения другими членами социума не пресекаются, и, как следствие, перестаёт считать правила (причём не только те, нарушения которых он наблюдал, но и любые другие) обязательными для себя. При этом условная средняя планка «допустимого нарушения» в обществе постоянно понижается, и рано или поздно это приводит к увеличению числа уже серьёзных преступлений.
Абсолютно то же самое применимо в нашей работе каждый день.
Многие считают меня занудой, потому что я прошу вовремя двигать задачи, писать сообщения к коммитам как положено, вовремя писать в стендап канал, извещать заранее о встречах, задачах, проблемах, а не в последнюю секунду и т. д.
Казалось бы, мелочи какие-то, ведь и так можно же жить, если раз-два срезать угол, забить на несколько правил. В краткосрочной перспективе, особенно если ты работаешь один, а не в команде, это действительно может вполне неплохо работать. Однако при работе в команде каждый срезанный угол порождает не только желание его срезать у других членов команды, но даже и неприятную обиду «А почему он так может делать, а мне нельзя? Он что, лучше меня?».
Поэтому я всегда рекомендую, если уж вы договорились о каком-то процессе, то следуйте ему. Если он не нравится, неудобный, потерял актуальность – соберитесь, обсудите, передоговоритесь и следуйте спокойно уже новым правилам.
Я понимаю, что мы не живем в идеальном мире и порой правда надо где-то «разбить окошко». В таком случае я стараюсь делать это публично, декларируя, что сейчас такая ситуация, что я тут малость косякну, но это разовая акция, не думайте. Когда это действительно разовая акция, и ты объяснил почему так, это не провоцирует других за тобой повторять и на тебя обижаться.
Итог
Если хотите порядочек и дисциплину – не закрывайте глаза на мелочи. Непрерывный контроль (в идеале максимально автоматизированный) - это главный помощник в борьбе с энтропией любого масштаба.
Существует криминологическая теория, которая утверждает, что попустительство общества к мелким правонарушениям, таким как выбрасывание мусора в неустановленных для этого местах, вандализм, публичное пьянство, прыжки через турникеты в метро и прочие, непосредственно провоцирует людей на совершение аналогичных или более серьёзных правонарушений.
Психологический механизм такой провокации на бытовом уровне иллюстрируется следующей фразой: «Если другим можно, то почему нельзя мне?». Человек видит, что нарушения правил поведения другими членами социума не пресекаются, и, как следствие, перестаёт считать правила (причём не только те, нарушения которых он наблюдал, но и любые другие) обязательными для себя. При этом условная средняя планка «допустимого нарушения» в обществе постоянно понижается, и рано или поздно это приводит к увеличению числа уже серьёзных преступлений.
Абсолютно то же самое применимо в нашей работе каждый день.
Многие считают меня занудой, потому что я прошу вовремя двигать задачи, писать сообщения к коммитам как положено, вовремя писать в стендап канал, извещать заранее о встречах, задачах, проблемах, а не в последнюю секунду и т. д.
Казалось бы, мелочи какие-то, ведь и так можно же жить, если раз-два срезать угол, забить на несколько правил. В краткосрочной перспективе, особенно если ты работаешь один, а не в команде, это действительно может вполне неплохо работать. Однако при работе в команде каждый срезанный угол порождает не только желание его срезать у других членов команды, но даже и неприятную обиду «А почему он так может делать, а мне нельзя? Он что, лучше меня?».
Поэтому я всегда рекомендую, если уж вы договорились о каком-то процессе, то следуйте ему. Если он не нравится, неудобный, потерял актуальность – соберитесь, обсудите, передоговоритесь и следуйте спокойно уже новым правилам.
Я понимаю, что мы не живем в идеальном мире и порой правда надо где-то «разбить окошко». В таком случае я стараюсь делать это публично, декларируя, что сейчас такая ситуация, что я тут малость косякну, но это разовая акция, не думайте. Когда это действительно разовая акция, и ты объяснил почему так, это не провоцирует других за тобой повторять и на тебя обижаться.
Итог
Если хотите порядочек и дисциплину – не закрывайте глаза на мелочи. Непрерывный контроль (в идеале максимально автоматизированный) - это главный помощник в борьбе с энтропией любого масштаба.
👍2
УДОЛИ!
Была у меня одна проблема. Когда я ходил в отпуск, я всё равно постоянно оставался на связи. Казалось бы, в чем проблема? Ну немножко слак почитал, ответил что-то в почте. Как мне это могло навредить за 10-20 минут такой активности в день?
А вредило это достаточно сильно. После отпуска складывалось ощущение, что я и не переставал работать. Все рабочие ситуации, проблемы, дискуссии – всё это не прекращалось. Каждый день, хотя бы ненадолго, я это продолжал впитывать.
Я знаю, что я далеко не один такой «ответственный», и вижу, что подобная проблема терзает многих. Потому вот вам очередной очевиднейший лайфхак для спокойного отдыха, которым я стал пользоваться уже давненько.
Удалите рабочий мессенджер и почтовый клиент
Удалите слак и почту, а пароль успешно забудьте (у вас же есть менеджер паролей, так ведь?). Так гораздо легче не сорваться в пылу трудоголизма и не начать заново всё устанавливать, чтобы «одним глазочком проверить, пока в метро еду».
Есть иногда загвоздка, когда рабочие переписки у вас идут в одном мессенджере с личными. Например, в телеграме. Тогда телеграм не удалить, можно только замьютить чатики, но это, конечно, не то. По-любому захочется зайти и прочитать, а сделать это будет очень легко. В таком случае я бы рекомендовал выйти из чатов, а зайти уже после отпуска, или завести второй аккаунт чисто для работы. Либо задуматься о том, что вы уничтожаете свои нервы, работая и живя бытовой жизнью в одном мессенджере. Это же страшное дело в долгосрочной перспективе.
И еще нюанс специально для тех, без кого всё на свете сломается, никто ничего не сделает, работа взорвется, а мир пропадет (конечно же, это не так, не обманывайте себя и окружающих). Если уж ваша натура категорически противится обрубанию контактов с работой на время отпуска, то всегда есть лазейки на случай, если правда дело плохо. В крайнем случае вас найдут и по телефону, и в личном мессенджере. Ваша задача тут одна: бить по рукам оборзевшим гражданам, которые не ценят чужой отдых и пишут/звонят без острой необходимости.
С тех пор, как я стал практиковать удаление средств рабочего общения с телефона, отпуска стали приносить больше отдыха, а на работу после них выходить проще и приятнее. Хотя бы нет такого чувства, что после отпуска совсем не хочется возвращаться.
Итог
Цените свой и чужой отдых. За неделю-две без вас мир не остановится, работа не развалится. А если это и случится, то значит, что-то не так с тем, как вы построили свой трудовой процесс.
Удаляйте мессенджеры и почты, перезагружайте мозги. Давайте отдохнуть другим, не тревожьте людей в отпуске без суперважнойсрочнойнеобходимойсупергорящей причины.
Была у меня одна проблема. Когда я ходил в отпуск, я всё равно постоянно оставался на связи. Казалось бы, в чем проблема? Ну немножко слак почитал, ответил что-то в почте. Как мне это могло навредить за 10-20 минут такой активности в день?
А вредило это достаточно сильно. После отпуска складывалось ощущение, что я и не переставал работать. Все рабочие ситуации, проблемы, дискуссии – всё это не прекращалось. Каждый день, хотя бы ненадолго, я это продолжал впитывать.
Я знаю, что я далеко не один такой «ответственный», и вижу, что подобная проблема терзает многих. Потому вот вам очередной очевиднейший лайфхак для спокойного отдыха, которым я стал пользоваться уже давненько.
Удалите рабочий мессенджер и почтовый клиент
Удалите слак и почту, а пароль успешно забудьте (у вас же есть менеджер паролей, так ведь?). Так гораздо легче не сорваться в пылу трудоголизма и не начать заново всё устанавливать, чтобы «одним глазочком проверить, пока в метро еду».
Есть иногда загвоздка, когда рабочие переписки у вас идут в одном мессенджере с личными. Например, в телеграме. Тогда телеграм не удалить, можно только замьютить чатики, но это, конечно, не то. По-любому захочется зайти и прочитать, а сделать это будет очень легко. В таком случае я бы рекомендовал выйти из чатов, а зайти уже после отпуска, или завести второй аккаунт чисто для работы. Либо задуматься о том, что вы уничтожаете свои нервы, работая и живя бытовой жизнью в одном мессенджере. Это же страшное дело в долгосрочной перспективе.
И еще нюанс специально для тех, без кого всё на свете сломается, никто ничего не сделает, работа взорвется, а мир пропадет (конечно же, это не так, не обманывайте себя и окружающих). Если уж ваша натура категорически противится обрубанию контактов с работой на время отпуска, то всегда есть лазейки на случай, если правда дело плохо. В крайнем случае вас найдут и по телефону, и в личном мессенджере. Ваша задача тут одна: бить по рукам оборзевшим гражданам, которые не ценят чужой отдых и пишут/звонят без острой необходимости.
С тех пор, как я стал практиковать удаление средств рабочего общения с телефона, отпуска стали приносить больше отдыха, а на работу после них выходить проще и приятнее. Хотя бы нет такого чувства, что после отпуска совсем не хочется возвращаться.
Итог
Цените свой и чужой отдых. За неделю-две без вас мир не остановится, работа не развалится. А если это и случится, то значит, что-то не так с тем, как вы построили свой трудовой процесс.
Удаляйте мессенджеры и почты, перезагружайте мозги. Давайте отдохнуть другим, не тревожьте людей в отпуске без суперважнойсрочнойнеобходимойсупергорящей причины.
Брать ли сотрудника назад?
Порой бывает такая ситуация: человек увольняется, идет за лучшими условиями, они оказываются только на словах, и в итоге сотрудник желает вернуться назад.
Как всегда, в этой ситуации есть два стула. На одном стуле грозно потрясают кулаком и кричат «НАЗАД НЕ БЕРЕМ!», а на другом – более миролюбивые и позволяют вернуться, если есть такая возможность.
Я подобных решений еще не принимал, однако был у меня один коллега, которому я был бы очень рад, если б он вернулся. Когда он увольнялся, я топил за то, чтобы позвать его обратно, если ему не понравится на новом месте и, если он сам захочет.
На мой взгляд, если совместная работа была комфортной, и вы расстаетесь полюбовно, то, взяв сотрудника назад, вы можете получить его высокую лояльность и меньшее желание уходить вновь. В такой ситуации человек сам понимает, что где-то там заманчивые обещания запросто могут обернуться фигнёй, а тут уже известный уровень хорошести, плюс его так любят, ценят, уважают, что готовы назад принять и дальше с удовольствием работать. Лично для меня это было бы очень жирным плюсом к долгосрочной работе в такой команде.
Но здесь, конечно, всё индивидуально. Так как я сам человек, ценящий стабильность и хорошее отношение, то мне кажется этот вариант неплохим. Хотя есть куча и других условий, когда это может не сработать:
- Человек – неисправимый гастролер, который будет использовать доброе отношение только как резервный аэродром, если на новом месте все пошло не так.
- В человеке еще до его ухода были некие сомнения, и лучше не надеяться, что он «перевоспитается».
- У вас такой темп и текучка кадров, что некогда дожидаться, пока работник там определится. Да и вообще у вас мало кто задерживается надолго, вы же галера.
Итог
Если вы позиционируете себя, как уютный дружный коллектив, то хотя бы рассмотрите вариант приема хорошего человека назад после того, как он попробовал что-то изменить к лучшему, но ошибся. Он будет вам благодарен.
Но тщательно взвешивайте и свою текущую ситуацию, и то, насколько этот человек действительно хорош. Некоторых лучше отпустить и забыть)
Порой бывает такая ситуация: человек увольняется, идет за лучшими условиями, они оказываются только на словах, и в итоге сотрудник желает вернуться назад.
Как всегда, в этой ситуации есть два стула. На одном стуле грозно потрясают кулаком и кричат «НАЗАД НЕ БЕРЕМ!», а на другом – более миролюбивые и позволяют вернуться, если есть такая возможность.
Я подобных решений еще не принимал, однако был у меня один коллега, которому я был бы очень рад, если б он вернулся. Когда он увольнялся, я топил за то, чтобы позвать его обратно, если ему не понравится на новом месте и, если он сам захочет.
На мой взгляд, если совместная работа была комфортной, и вы расстаетесь полюбовно, то, взяв сотрудника назад, вы можете получить его высокую лояльность и меньшее желание уходить вновь. В такой ситуации человек сам понимает, что где-то там заманчивые обещания запросто могут обернуться фигнёй, а тут уже известный уровень хорошести, плюс его так любят, ценят, уважают, что готовы назад принять и дальше с удовольствием работать. Лично для меня это было бы очень жирным плюсом к долгосрочной работе в такой команде.
Но здесь, конечно, всё индивидуально. Так как я сам человек, ценящий стабильность и хорошее отношение, то мне кажется этот вариант неплохим. Хотя есть куча и других условий, когда это может не сработать:
- Человек – неисправимый гастролер, который будет использовать доброе отношение только как резервный аэродром, если на новом месте все пошло не так.
- В человеке еще до его ухода были некие сомнения, и лучше не надеяться, что он «перевоспитается».
- У вас такой темп и текучка кадров, что некогда дожидаться, пока работник там определится. Да и вообще у вас мало кто задерживается надолго, вы же галера.
Итог
Если вы позиционируете себя, как уютный дружный коллектив, то хотя бы рассмотрите вариант приема хорошего человека назад после того, как он попробовал что-то изменить к лучшему, но ошибся. Он будет вам благодарен.
Но тщательно взвешивайте и свою текущую ситуацию, и то, насколько этот человек действительно хорош. Некоторых лучше отпустить и забыть)
👍1
Кодревью. Нужно или нет?
В последнее время случилось много обсуждений полезности и бесполезности кодревью.
Самые интересные можно послушать у подкаста SDCast https://sdcast.ksdaemon.ru/2020/07/sdcast-121/ и у ребят из Podlodka Teamlead Crew https://www.youtube.com/watch?v=IDj3x__YZgE
Если не хотите слушать, то частые два противоположных мнения таковы:
Стул №1. Кодревью нужно
Надо делать обязательно, а иначе наговнокодят, будет плохая архитектура, наберем техдолга, потом концов не сыщешь в том, кто прав, кто виноват, что с этим теперь делать.
Стул №2. Кодревью не нужно
Что мы тут взрослым людям сопли подтираем, релиз задач блокируем, время тратим. Нормально делай – нормально будет.
Между стульями
В связи с приходом в команду новых джунов и в целом расслоением команды на новичков, не знающих проекты, середнячков, знающих часть проектов и опытных ребят, делавших большинство (или все) этих проектов своими руками, я решил рассказать о своем видении кодревью.
На мой взгляд, кодревью для джунов строго обязательно. Пока апрува нет – в прод не уходит. Каждый вздох, чих, взгляд, букву (утрирую немножко) надо отсмотреть и проверить. Тут без строгого контроля можно не просто плохую архитектуру заиметь, а еще и упавший прод.
Кодревью для мидлов – ну пусть оно будет не такое строгое, не блокирующее релиз в большинстве задач, кроме каких-то критических, развесистых, сложных. Однако глазами надо внимательно за ними проверять более опытному товарищу.
За матерыми и опытными ребятами по-хорошему можно и не следить. Это и правда в большинстве случаев трата времени и замедление релиза.
Тем не менее я за то, чтобы по возможности пробегаться по коду даже матерых товарищей. Больше даже не с целью баги найти, а просто быть в курсе, что как делается. Чтобы потом не офигевать, когда коллега в отпуске, а вы совсем не в курсе, что творится в его куске кода, который надо поправить (привет всем тем, кто не пишет документацию).
Итог
Я не думаю, что надо однозначно решать делать кодревью для всего на свете, или наоборот ни для чего не делать. Смотрите по сотрудникам, их компетенциям, ответственности, внимательности, уровню задач.
В последнее время случилось много обсуждений полезности и бесполезности кодревью.
Самые интересные можно послушать у подкаста SDCast https://sdcast.ksdaemon.ru/2020/07/sdcast-121/ и у ребят из Podlodka Teamlead Crew https://www.youtube.com/watch?v=IDj3x__YZgE
Если не хотите слушать, то частые два противоположных мнения таковы:
Стул №1. Кодревью нужно
Надо делать обязательно, а иначе наговнокодят, будет плохая архитектура, наберем техдолга, потом концов не сыщешь в том, кто прав, кто виноват, что с этим теперь делать.
Стул №2. Кодревью не нужно
Что мы тут взрослым людям сопли подтираем, релиз задач блокируем, время тратим. Нормально делай – нормально будет.
Между стульями
В связи с приходом в команду новых джунов и в целом расслоением команды на новичков, не знающих проекты, середнячков, знающих часть проектов и опытных ребят, делавших большинство (или все) этих проектов своими руками, я решил рассказать о своем видении кодревью.
На мой взгляд, кодревью для джунов строго обязательно. Пока апрува нет – в прод не уходит. Каждый вздох, чих, взгляд, букву (утрирую немножко) надо отсмотреть и проверить. Тут без строгого контроля можно не просто плохую архитектуру заиметь, а еще и упавший прод.
Кодревью для мидлов – ну пусть оно будет не такое строгое, не блокирующее релиз в большинстве задач, кроме каких-то критических, развесистых, сложных. Однако глазами надо внимательно за ними проверять более опытному товарищу.
За матерыми и опытными ребятами по-хорошему можно и не следить. Это и правда в большинстве случаев трата времени и замедление релиза.
Тем не менее я за то, чтобы по возможности пробегаться по коду даже матерых товарищей. Больше даже не с целью баги найти, а просто быть в курсе, что как делается. Чтобы потом не офигевать, когда коллега в отпуске, а вы совсем не в курсе, что творится в его куске кода, который надо поправить (привет всем тем, кто не пишет документацию).
Итог
Я не думаю, что надо однозначно решать делать кодревью для всего на свете, или наоборот ни для чего не делать. Смотрите по сотрудникам, их компетенциям, ответственности, внимательности, уровню задач.
SDCast
SDCast #121: Круглый стол про код-ревью
Товарищи, в этот раз вас ждёт необычный выпуск подкаста! Почему? — Этот выпуск был записан в прямом эфире с обсуждением вопросов зрителей, онлайн-голосованиями и другими активностями. Но не переживайте, весь контент доступен для восприятия в аудио-формате…
Как быстро научиться?
В ИТ довольно много и регулярно приходится изучать информации, осмысливать её, применять на практике. Это касается как разработки, так и менеджмента.
Часто я сталкиваюсь с тем, что человек хочет работать, зарабатывать, карьерно расти, а как-то серьезно учиться не хочет.
Вместо книги он хочет статью на хабре за 5 минут прочитать или видосик на ютубе за 7.5 минут посмотреть. Вместо основательного курса на N месяцев лучше сходить на 2-3-4-дневный интенсив, где реклама обещает тебе море знаний и умений.
Интересно здесь то, что позиция «хочу получать много денях, при этом особо не напрягаясь» этих людей мало смущает. На вопрос «за что тебе будут много платить, если ты прошел трехдневный курс и посмотрел пять видосов на ютубе?» разумного ответа обычно нет. Просто потому что.
Но если вдруг ваш врач будет учиться по ютубным роликам, ваш юрист, строитель вашего дома, ваш фитнес тренер, да практически кто угодно, то это вызовет некоторые неприятные сомнения. А вот в ИТ, где бабло пока еще льется рекой, этих сомнений почему-то особо и нет.
В целом я не отрицаю полезность коротких форм обучения. Они помогают понять базовые основы, или почерпнуть какие-нибудь тонкости или новинки в уже известных темах, разобраться, нужно ли вам оно вообще, стоит ли вам углубляться. Однако, если вы хотите дальше это профессионально применять, то в большинстве случаев за коротким вводным курсом должно следовать что-то более серьезное и основательное.
Итог
Как быстро чему-то научиться, чтобы этих знаний хватило в будущем для спокойной, стабильной, профессиональной работы? Никак.
Если вы действительно способны основательно учиться, копать вглубь, не бояться работы, то можете быть спокойны. Пока существуют экспресс курсы и толпы желающих срезать углы, то с вашей работой и стабильностью всё будет в порядке.
В ИТ довольно много и регулярно приходится изучать информации, осмысливать её, применять на практике. Это касается как разработки, так и менеджмента.
Часто я сталкиваюсь с тем, что человек хочет работать, зарабатывать, карьерно расти, а как-то серьезно учиться не хочет.
Вместо книги он хочет статью на хабре за 5 минут прочитать или видосик на ютубе за 7.5 минут посмотреть. Вместо основательного курса на N месяцев лучше сходить на 2-3-4-дневный интенсив, где реклама обещает тебе море знаний и умений.
Интересно здесь то, что позиция «хочу получать много денях, при этом особо не напрягаясь» этих людей мало смущает. На вопрос «за что тебе будут много платить, если ты прошел трехдневный курс и посмотрел пять видосов на ютубе?» разумного ответа обычно нет. Просто потому что.
Но если вдруг ваш врач будет учиться по ютубным роликам, ваш юрист, строитель вашего дома, ваш фитнес тренер, да практически кто угодно, то это вызовет некоторые неприятные сомнения. А вот в ИТ, где бабло пока еще льется рекой, этих сомнений почему-то особо и нет.
В целом я не отрицаю полезность коротких форм обучения. Они помогают понять базовые основы, или почерпнуть какие-нибудь тонкости или новинки в уже известных темах, разобраться, нужно ли вам оно вообще, стоит ли вам углубляться. Однако, если вы хотите дальше это профессионально применять, то в большинстве случаев за коротким вводным курсом должно следовать что-то более серьезное и основательное.
Итог
Как быстро чему-то научиться, чтобы этих знаний хватило в будущем для спокойной, стабильной, профессиональной работы? Никак.
Если вы действительно способны основательно учиться, копать вглубь, не бояться работы, то можете быть спокойны. Пока существуют экспресс курсы и толпы желающих срезать углы, то с вашей работой и стабильностью всё будет в порядке.
Что будет, если я не успею?
В одном из постов я уже вскользь затрагивал применение этого вопроса, но сегодня хотел бы мысль раскрыть чуть подробнее. Надеюсь, это облегчит жизнь тем, кто не читал предыдущие посты, но сможет теперь начать применять данную методику.
Суть проблемы
Прилетает (например, как чайка) менеджер или заказчик, кричит, что задачу надо сделать СРОЧНО и улетает. Вы всё бросаете, в мыле делаете задачу, может, даже овертаймите. С гордым видом победителя сдаете задачу и…. ничего не происходит. Задачу отложили на попозже, ты, конечно, молодец, что сделал, но внедрим как-нибудь потом, а щас пока вот тебе еще пучок срочных, беги скорее исполнять.
Почему так происходит?
Происходить это может по многим причинам, и валидных там не так много. Понятно, что бывает действительно надо срочно, или в самом конце перед внедрением планы меняются. Это нормально, это жизнь.
Однако есть еще варианты:
- «скажу им, что срочно, а то эти работнички вечно не торопятся»;
- «скажу, что срочно, чтобы среди задач от других отделов мою взяли побыстрее»;
- «скажу «срочно», потому что я неорганизованный менеджер, у которого каждый день что-то горит»;
- «скажу «срочно», потому что лень думать, планировать, согласовывать, пущай сделают прям щас, а там как-нибудь разберусь»;
и многие подобные причины.
Что делать?
Когда я вижу сомнительные, ничем вроде бы неподкрепленные срочные сроки, то я спрашиваю: «Что будет, если я не успею?». Ответы «ну очень надо», «будет плохо», «попросили» не принимаются. Хочется услышать конкретику, что конкретно случится, если запрошенная работа не будет сделана к короткому жесткому дедлайну.
Бывают очевидные случаи, когда заказчик объясняет, почему надо поднажать, иначе будет вот так и эдак плохо. Однако часто встречается и такое, когда оказывается, что ничего плохого и не произойдет. И задача может оказаться не срочной. И вообще там еще надо согласовать, обговорить, встретиться, передумать пару раз, а потом только делать.
Почему этот вопрос «что будет, если я не успею?» так помогает?
- Он стимулирует заказчика еще раз обдумать жизненный цикл фичи и хорошенько заняться планированием. В результате чего могут появиться новые мысли и открытия.
- Он выжимает конкретику, а значит вскрывает недобросовестных врунишек, которые просто притворяются, что от них любая задача – вершина срочности.
- Он позволяет подумать о рисках и заложить резервные альтернативные решения.
- Он позволяет вам самим получить понимание, что ваше время уважают, а вашу работу ценят и не складируют в стол «просто потому что».
Отдельно стоит сказать о том, что не надо бояться спрашивать, уточнять, разбираться. В этом нет ничего плохого или стыдного. Страх «а как же я спрошу, ведь он заказчик/начальник? Что он обо мне подумает?» не очень рационален. Если это толковый начальник, то он только порадуется тому, что вы обладаете пытливым умом и стремитесь разобраться в ситуации, а не просто берете под козырек и бросаетесь выполнять. А если бестолковый и работает по принципу «я – начальник, ты – дурак, выполняй!», то чем раньше вы это поймете, тем быстрее смекнете о своих дальнейших перспективах на этой работе.
Итог
Если вы менеджер – цените и уважайте чужое время и труд. Планируйте нормально, продумывайте будущее. Ведь это ваша основная работа.
Если вы исполнитель – не стесняйтесь спрашивать и добиваться конкретики, вы и менеджеру поможете, и бестолковых на чистую воду выведете, и себе время с нервами сэкономите.
В одном из постов я уже вскользь затрагивал применение этого вопроса, но сегодня хотел бы мысль раскрыть чуть подробнее. Надеюсь, это облегчит жизнь тем, кто не читал предыдущие посты, но сможет теперь начать применять данную методику.
Суть проблемы
Прилетает (например, как чайка) менеджер или заказчик, кричит, что задачу надо сделать СРОЧНО и улетает. Вы всё бросаете, в мыле делаете задачу, может, даже овертаймите. С гордым видом победителя сдаете задачу и…. ничего не происходит. Задачу отложили на попозже, ты, конечно, молодец, что сделал, но внедрим как-нибудь потом, а щас пока вот тебе еще пучок срочных, беги скорее исполнять.
Почему так происходит?
Происходить это может по многим причинам, и валидных там не так много. Понятно, что бывает действительно надо срочно, или в самом конце перед внедрением планы меняются. Это нормально, это жизнь.
Однако есть еще варианты:
- «скажу им, что срочно, а то эти работнички вечно не торопятся»;
- «скажу, что срочно, чтобы среди задач от других отделов мою взяли побыстрее»;
- «скажу «срочно», потому что я неорганизованный менеджер, у которого каждый день что-то горит»;
- «скажу «срочно», потому что лень думать, планировать, согласовывать, пущай сделают прям щас, а там как-нибудь разберусь»;
и многие подобные причины.
Что делать?
Когда я вижу сомнительные, ничем вроде бы неподкрепленные срочные сроки, то я спрашиваю: «Что будет, если я не успею?». Ответы «ну очень надо», «будет плохо», «попросили» не принимаются. Хочется услышать конкретику, что конкретно случится, если запрошенная работа не будет сделана к короткому жесткому дедлайну.
Бывают очевидные случаи, когда заказчик объясняет, почему надо поднажать, иначе будет вот так и эдак плохо. Однако часто встречается и такое, когда оказывается, что ничего плохого и не произойдет. И задача может оказаться не срочной. И вообще там еще надо согласовать, обговорить, встретиться, передумать пару раз, а потом только делать.
Почему этот вопрос «что будет, если я не успею?» так помогает?
- Он стимулирует заказчика еще раз обдумать жизненный цикл фичи и хорошенько заняться планированием. В результате чего могут появиться новые мысли и открытия.
- Он выжимает конкретику, а значит вскрывает недобросовестных врунишек, которые просто притворяются, что от них любая задача – вершина срочности.
- Он позволяет подумать о рисках и заложить резервные альтернативные решения.
- Он позволяет вам самим получить понимание, что ваше время уважают, а вашу работу ценят и не складируют в стол «просто потому что».
Отдельно стоит сказать о том, что не надо бояться спрашивать, уточнять, разбираться. В этом нет ничего плохого или стыдного. Страх «а как же я спрошу, ведь он заказчик/начальник? Что он обо мне подумает?» не очень рационален. Если это толковый начальник, то он только порадуется тому, что вы обладаете пытливым умом и стремитесь разобраться в ситуации, а не просто берете под козырек и бросаетесь выполнять. А если бестолковый и работает по принципу «я – начальник, ты – дурак, выполняй!», то чем раньше вы это поймете, тем быстрее смекнете о своих дальнейших перспективах на этой работе.
Итог
Если вы менеджер – цените и уважайте чужое время и труд. Планируйте нормально, продумывайте будущее. Ведь это ваша основная работа.
Если вы исполнитель – не стесняйтесь спрашивать и добиваться конкретики, вы и менеджеру поможете, и бестолковых на чистую воду выведете, и себе время с нервами сэкономите.