календарь менеджера
так уж повелось, что календарь менеджера — это сплошное полотно из созвонов и созвонов.
я, разумеется, не являюсь исключением.
но работа менеджера — не только балакать, но и мешки ворочать.
очевидным решением для себя я нашел столбление слотов в календаре под концентрацию. зачастую делаю их приватными, чтобы даже не лезли.
но вот минус — не всегда в эти отведенные промежутки в слотах ты будешь делать то, что нужно.
следующей генерацией от меня было сделать слот "задачи и цели" и в рамках слота точно иметь время на это.
однако, в это время почти всегда происходят форс-мажоры и важные событие вовне, которые отвлекают от этих дел.
соблюдать ворк-лайф беленс нужно. поэтому, не жертвуя личным временем, оптимизируем встречи — приходим готовыми, делаем на них ровно то, что нужно, делегируем встречи, на которых нам лично быть не нужно, а еще прямо во время встречи если понимаем что нет смысла на них быть — уходим (можно даже предлог написать в виде "я на инц")
главное — не сойти с ума и не потерять контексты между встречами, поэтому ставьте себе либо кратные 15 минутам встречи с зазором в эти самые 15 минут, либо ведите заметки по ходу встречи, а вечером — делайте разбор заметок. не откладыайте на утро, утром все изменится.
а еще — если откладывать на завтра — завтра наступит внезапно и там будет еще 10+ новых задач и встреч.
расшивка календаря круто, но реальность кусь за жопу.
какое счастье, когда "встреча отменена"🍊
эта встреча могла быть емейлом!!!
так уж повелось, что календарь менеджера — это сплошное полотно из созвонов и созвонов.
я, разумеется, не являюсь исключением.
но работа менеджера — не только балакать, но и мешки ворочать.
очевидным решением для себя я нашел столбление слотов в календаре под концентрацию. зачастую делаю их приватными, чтобы даже не лезли.
но вот минус — не всегда в эти отведенные промежутки в слотах ты будешь делать то, что нужно.
следующей генерацией от меня было сделать слот "задачи и цели" и в рамках слота точно иметь время на это.
однако, в это время почти всегда происходят форс-мажоры и важные событие вовне, которые отвлекают от этих дел.
соблюдать ворк-лайф беленс нужно. поэтому, не жертвуя личным временем, оптимизируем встречи — приходим готовыми, делаем на них ровно то, что нужно, делегируем встречи, на которых нам лично быть не нужно, а еще прямо во время встречи если понимаем что нет смысла на них быть — уходим (можно даже предлог написать в виде "я на инц")
главное — не сойти с ума и не потерять контексты между встречами, поэтому ставьте себе либо кратные 15 минутам встречи с зазором в эти самые 15 минут, либо ведите заметки по ходу встречи, а вечером — делайте разбор заметок. не откладыайте на утро, утром все изменится.
а еще — если откладывать на завтра — завтра наступит внезапно и там будет еще 10+ новых задач и встреч.
расшивка календаря круто, но реальность кусь за жопу.
какое счастье, когда "встреча отменена"
эта встреча могла быть емейлом!!!
Please open Telegram to view this post
VIEW IN TELEGRAM
🫡12👍6🤝4❤🔥2🎉1
пирамида сыча
да вряд ли сыча, просто хочется подумать над тем, что в работе для меня важнее всего. на днях обсуждали с коллегой эту историю, решил как-то формализовать критерии критичности условий на работе для меня
сверху-вниз (чем выше — тем важнее)
нулевой слой — не заставлять делать дичь: переступать мораль, законы, увольнять всех неугодных руководству, продавать в рабство инженеров, убивать людей, гемблинг, наркотики, железные сервера руками
дальше, в адекватную первую очередь идет, конечно же, оплата труда и сфера труда — айти. это какой-то базис, без которого я работать не буду)) а так — на что продал — на то и работаю) дальше уже перф-ревью или рынок решит
честность и открытость между мной и руководителем, а так же прямыми пирами — я это всегда делаю сам, но мне важно, чтобы со мной были честными во всем
степень известности — важно чтобы цели были понятны, куда они приведут и как их корректируют исходя из происходящего
удаленная работа — для меня теперь стала еще важнее, я умею, могу и буду работать удаленно
коллеги, а точнее — те, кого не хочется звать коллегами, а хочется назвать братаны/сестраны, капибарята, в общем — коллектив, который поддержит, поможет, сделает то, что нужно и как нужно
сюда же добавлю кружки по интересам, которые можно открывать и лидировать + пушить в правильном русле
атмосфера правильной токсичности — кого надо облить, кого не надо — помочь, не стесняться критиковать и получать критику адекватно
интересные задачи — не однородный поток коричневых задач, а разнообразные задачи, в которых я могу решать и выбирать
обратная связь — 360/180 и прочие циферки, но лишь бы доносили что я делаю что-то не так (или так, тоже норм)
техника — либо работать на технике компании, либо без ограничений на собственной (типа ставить DLP на свою? нееее)
ДМС, премии — вообще пофиг, если честно
аминь, елочка зажгись!
да вряд ли сыча, просто хочется подумать над тем, что в работе для меня важнее всего. на днях обсуждали с коллегой эту историю, решил как-то формализовать критерии критичности условий на работе для меня
сверху-вниз (чем выше — тем важнее)
нулевой слой — не заставлять делать дичь: переступать мораль, законы, увольнять всех неугодных руководству, продавать в рабство инженеров, убивать людей, гемблинг, наркотики, железные сервера руками
дальше, в адекватную первую очередь идет, конечно же, оплата труда и сфера труда — айти. это какой-то базис, без которого я работать не буду)) а так — на что продал — на то и работаю) дальше уже перф-ревью или рынок решит
честность и открытость между мной и руководителем, а так же прямыми пирами — я это всегда делаю сам, но мне важно, чтобы со мной были честными во всем
степень известности — важно чтобы цели были понятны, куда они приведут и как их корректируют исходя из происходящего
удаленная работа — для меня теперь стала еще важнее, я умею, могу и буду работать удаленно
коллеги, а точнее — те, кого не хочется звать коллегами, а хочется назвать братаны/сестраны, капибарята, в общем — коллектив, который поддержит, поможет, сделает то, что нужно и как нужно
сюда же добавлю кружки по интересам, которые можно открывать и лидировать + пушить в правильном русле
атмосфера правильной токсичности — кого надо облить, кого не надо — помочь, не стесняться критиковать и получать критику адекватно
интересные задачи — не однородный поток коричневых задач, а разнообразные задачи, в которых я могу решать и выбирать
обратная связь — 360/180 и прочие циферки, но лишь бы доносили что я делаю что-то не так (или так, тоже норм)
техника — либо работать на технике компании, либо без ограничений на собственной (типа ставить DLP на свою? нееее)
ДМС, премии — вообще пофиг, если честно
аминь, елочка зажгись!
❤🔥8👍4
играющий тренер
вот все кручу, кручу этого играющего тренера и не могу отделаться от мысли — те, кто ожидает играющего тренера — всегда получают и не тренера, и не игрока.
почему? потому что если инженер вырос в менеджера — ему нужно расти в менеджерстве, там много чего есть и обуять это быстро и качественно — невозможно
когда менеджер хочет инженерить — это круто, он может и будет это делать. но дальше нужно понимать какое соотношение инженерных задач к менеджерским будет и как к этому готов каждый конкретный лидер.
закладывать капаситет лида в командный — считаю точно неправильным. пусть это всегда будет приятный бонус и ускорение в моменте.
при этом, для компании получить "играющего тренера" на самом деле проблема — они не получат адекватной менеджерской поддержки и не получат полноценно инженера.
ни в коем случае не говорю, что становясь менеджером, нужно забыть инженерку и стать бумажкоперекладывателем. можно и нужно продолжать быть в тренде, понимать что происходит и держать контекст. самый простой способ — участие в код-ревью и архитектурном комитете на уровне полноценного участника, а не просто принимающего решения человека.
ну и да, будучи на высоких позициях (юнит-лид, head of, CTO) все эти вещи тоже работают.
ага, а если вы инженера грузите менеджерством — тоже может получиться вообще плохо (а может хорошо, но давайте об этом однажды еще поговорим)
вот все кручу, кручу этого играющего тренера и не могу отделаться от мысли — те, кто ожидает играющего тренера — всегда получают и не тренера, и не игрока.
почему? потому что если инженер вырос в менеджера — ему нужно расти в менеджерстве, там много чего есть и обуять это быстро и качественно — невозможно
когда менеджер хочет инженерить — это круто, он может и будет это делать. но дальше нужно понимать какое соотношение инженерных задач к менеджерским будет и как к этому готов каждый конкретный лидер.
закладывать капаситет лида в командный — считаю точно неправильным. пусть это всегда будет приятный бонус и ускорение в моменте.
при этом, для компании получить "играющего тренера" на самом деле проблема — они не получат адекватной менеджерской поддержки и не получат полноценно инженера.
ни в коем случае не говорю, что становясь менеджером, нужно забыть инженерку и стать бумажкоперекладывателем. можно и нужно продолжать быть в тренде, понимать что происходит и держать контекст. самый простой способ — участие в код-ревью и архитектурном комитете на уровне полноценного участника, а не просто принимающего решения человека.
ну и да, будучи на высоких позициях (юнит-лид, head of, CTO) все эти вещи тоже работают.
ага, а если вы инженера грузите менеджерством — тоже может получиться вообще плохо (а может хорошо, но давайте об этом однажды еще поговорим)
❤🔥11👍5
опыт
что вкладывается в понятие опыт?
багаж знаний, который есть у человека по определенной теме?
или практические навыки, полученные за годы работы с технологией или практикой?
мне кажется, опытный человек — это тот, который может сделать базовые вещи вообще не задумываясь, разобраться в контексте и необходимости сложных действий и спроектировать решение по необходимости изменений.
это касается не только айти или работы даже, в жизни же точно так же.
ну и да, невозможно стать сеньором за три года от старта. либо станешь только в своей узкой специализации, либо будешь дурачком, который считает что все знает и набивает себе этим цену. ни тех, ни других рынок не ценит.
обратная стороная — быть слишком широким универсалом без глубокой специализации в какой-то конкретной теме. всё вроде знает, но не может нигде нырнуть вглубь и дать экспертную оценку/совет.
бороться с этим? нет, просто надо понимать, что опыт — это штука, которая помогает, а не просто дает очков в резюме) а уж как она помогает — надо смотреть. кому-то может и мешает, потому что шоры глаза закрыли.
что вкладывается в понятие опыт?
багаж знаний, который есть у человека по определенной теме?
или практические навыки, полученные за годы работы с технологией или практикой?
мне кажется, опытный человек — это тот, который может сделать базовые вещи вообще не задумываясь, разобраться в контексте и необходимости сложных действий и спроектировать решение по необходимости изменений.
это касается не только айти или работы даже, в жизни же точно так же.
ну и да, невозможно стать сеньором за три года от старта. либо станешь только в своей узкой специализации, либо будешь дурачком, который считает что все знает и набивает себе этим цену. ни тех, ни других рынок не ценит.
обратная стороная — быть слишком широким универсалом без глубокой специализации в какой-то конкретной теме. всё вроде знает, но не может нигде нырнуть вглубь и дать экспертную оценку/совет.
бороться с этим? нет, просто надо понимать, что опыт — это штука, которая помогает, а не просто дает очков в резюме) а уж как она помогает — надо смотреть. кому-то может и мешает, потому что шоры глаза закрыли.
👍9❤5🤔4🤝1
команда и компания
в нелегкие времена задумываюсь вот о чем: сколько бы ни работал — всегда работаю с командой, а не с компанией.
возможно, поэтому мне не сильно важно в какой фирме работать (при прочих равных, см пост про пирамиду), а с какими людьми.
но ведь сложно понять что за люди и как они работают в конкретных условиях, не поработав с ними.
и тут есть варианты — работать со своими людьми (расширяя круг) и переходя с ними (или за ними) из компании в компанию, либо смотреть на компанию исходя из людей там и к ним притираться (или просто влиться как к себе домой)
я сторонник и того, и того подхода в зависимости от ситуации и конечно буду рад знакомым лицам, однако всегда когда поработаю в компании хотя бы чуть — начинаю работать с командой (или командами)
и вот, когда я перехожу к работе с командами — тогда уже лояльность работает в обе стороны полноценно — команда опирается на меня, я опираюсь на компанию и команду и служу связующим звеном между ними (если это требуется, конечно).
главное — найти свою команду, быть в ней полноценным участником — и тогда работа будет в кайф и тогда задачи будут интересные и всё получится. но не стоит питать иллюзий — если компания плохая — то и команде станет плохо, а там уже — смотри выше.
в нелегкие времена задумываюсь вот о чем: сколько бы ни работал — всегда работаю с командой, а не с компанией.
возможно, поэтому мне не сильно важно в какой фирме работать (при прочих равных, см пост про пирамиду), а с какими людьми.
но ведь сложно понять что за люди и как они работают в конкретных условиях, не поработав с ними.
и тут есть варианты — работать со своими людьми (расширяя круг) и переходя с ними (или за ними) из компании в компанию, либо смотреть на компанию исходя из людей там и к ним притираться (или просто влиться как к себе домой)
я сторонник и того, и того подхода в зависимости от ситуации и конечно буду рад знакомым лицам, однако всегда когда поработаю в компании хотя бы чуть — начинаю работать с командой (или командами)
и вот, когда я перехожу к работе с командами — тогда уже лояльность работает в обе стороны полноценно — команда опирается на меня, я опираюсь на компанию и команду и служу связующим звеном между ними (если это требуется, конечно).
главное — найти свою команду, быть в ней полноценным участником — и тогда работа будет в кайф и тогда задачи будут интересные и всё получится. но не стоит питать иллюзий — если компания плохая — то и команде станет плохо, а там уже — смотри выше.
👍16❤6
вы че там, всё безработным меня считаете?
не, я уже пришел звать вас ко мне в команду)
у нас есть две вакухи, на все вопросы отвечу
и да, я в🤪 lamoda tech
devops PaaS - https://hh.ru/vacancy/117744264
devops CI/CD - https://hh.ru/vacancy/117744435
не, я уже пришел звать вас ко мне в команду)
у нас есть две вакухи, на все вопросы отвечу
и да, я в
devops PaaS - https://hh.ru/vacancy/117744264
devops CI/CD - https://hh.ru/vacancy/117744435
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21❤5🤣4
онбординг
как театр начинается с вешалки (фу, клише!) так и работа в компании начинается с онбординга
я очень часто вижу, что на онбординг не выделяется должных сил и процесс превращается во что-то вроде "читай отсюда и до просветления" и "ну я когда пришел — тут даже звонка приветственного не было, онбординг не предусмотрен"
так вот, считаю что для работодателя критически важно сделать не просто хорошее приветствие, выдачу доступов и показать документацию (которой очень даже нет), но построить процесс онбординга таким, чтобы у новичка было ощущение нужности, долгожданности, чтобы он получил ответы на вопросы, которые даже не успел задать
прикольный онбординг был в сбермаркете — в джире автоматически создавались задачи на первый день, неделю, месяц и по ним легко можно было трекать что новичок сделал, где завис, где не получил доступ и что еще. прозрачно с обеих сторон.
альтернативный вариант — это страница вики с чеклистом, которую клонируют для каждого новичка и там он отмечает галочкой что сделал/получил.
очень клево, когда новичку выделяют ментора — человека, который от старта до завершения испыталки (может дальше) будет вести за ручку и помогать в спорных вопросах. при этом, почему-то, принятно такую опцию вешать на руководителя (что не есть правильно), тем самым сильно ограничивая скоуп знаний для новичка, а еще, в случае больших команд, расфокусировку или недостаточное погружение в технические процессы и детали (сам таким страдаю)
что ж, да) сейчас у нас онбординг очень хромает, но я знаю что сделать и как его сделать хорошим, а в будущем — даже лучшим.
и да, ребята, мне стыдно, но я исправлю
как театр начинается с вешалки (фу, клише!) так и работа в компании начинается с онбординга
я очень часто вижу, что на онбординг не выделяется должных сил и процесс превращается во что-то вроде "читай отсюда и до просветления" и "ну я когда пришел — тут даже звонка приветственного не было, онбординг не предусмотрен"
так вот, считаю что для работодателя критически важно сделать не просто хорошее приветствие, выдачу доступов и показать документацию (которой очень даже нет), но построить процесс онбординга таким, чтобы у новичка было ощущение нужности, долгожданности, чтобы он получил ответы на вопросы, которые даже не успел задать
прикольный онбординг был в сбермаркете — в джире автоматически создавались задачи на первый день, неделю, месяц и по ним легко можно было трекать что новичок сделал, где завис, где не получил доступ и что еще. прозрачно с обеих сторон.
альтернативный вариант — это страница вики с чеклистом, которую клонируют для каждого новичка и там он отмечает галочкой что сделал/получил.
очень клево, когда новичку выделяют ментора — человека, который от старта до завершения испыталки (может дальше) будет вести за ручку и помогать в спорных вопросах. при этом, почему-то, принятно такую опцию вешать на руководителя (что не есть правильно), тем самым сильно ограничивая скоуп знаний для новичка, а еще, в случае больших команд, расфокусировку или недостаточное погружение в технические процессы и детали (сам таким страдаю)
что ж, да) сейчас у нас онбординг очень хромает, но я знаю что сделать и как его сделать хорошим, а в будущем — даже лучшим.
и да, ребята, мне стыдно, но я исправлю
❤15👍11
уровни
на этой неделе сразу с несколькими коллегами, обсуждая разные темы, пришли к похожим мыслям.
у каждой организации есть определенный уровень развития (не путать со стадиями). как уровень зрелости или культуры.
если сотрудник приходит из компании с меньшим уровнем в большую, его ждет вызов и он будет круто (пусть и тяжело по началу) расти. либо, не справится и уйдет. но обычно, тянется к большинству.
а если человек идет на «понижение» — будет борьба за то, готова ли хотя бы его команда принять то новаторство и подходы, что он несет (а он может и не нести).
вряд ли компания сможет быстро вырасти с одного уровня на другой, а уж тем более, перескочить сразу несколько этапов развития. это значит лишь одно — нужно запастись терпением и желанием учить и слушать. корректируя путь свой и компании.
в командах все проще, но может обернуться расколом или нелояльностью части отличающихся уровнем зрелости людей.
может быть, есть известный способ определить уровень и как в них адаптироваться?
на этой неделе сразу с несколькими коллегами, обсуждая разные темы, пришли к похожим мыслям.
у каждой организации есть определенный уровень развития (не путать со стадиями). как уровень зрелости или культуры.
если сотрудник приходит из компании с меньшим уровнем в большую, его ждет вызов и он будет круто (пусть и тяжело по началу) расти. либо, не справится и уйдет. но обычно, тянется к большинству.
а если человек идет на «понижение» — будет борьба за то, готова ли хотя бы его команда принять то новаторство и подходы, что он несет (а он может и не нести).
вряд ли компания сможет быстро вырасти с одного уровня на другой, а уж тем более, перескочить сразу несколько этапов развития. это значит лишь одно — нужно запастись терпением и желанием учить и слушать. корректируя путь свой и компании.
в командах все проще, но может обернуться расколом или нелояльностью части отличающихся уровнем зрелости людей.
может быть, есть известный способ определить уровень и как в них адаптироваться?
🤔5💯5❤3👍2
попиарим
хочу поделиться с вами сборником айти канальчиков, который собирает крутой Дима Рыбалка.
я сам в части каналов состою, а остальные ситуативно поглядываю
сборник одобрен лучшими технарями, поэтому смело добавляйте)
и да, он обновляется
хочу поделиться с вами сборником айти канальчиков, который собирает крутой Дима Рыбалка.
я сам в части каналов состою, а остальные ситуативно поглядываю
сборник одобрен лучшими технарями, поэтому смело добавляйте)
и да, он обновляется
Telegram
IT_RUS
Dmitry Rybalka invites you to add the folder “IT_RUS”, which includes 39 chats.
🔥16👍5❤3
Forwarded from Lamoda Tech
На что влияют уровни зрелости компаний — с точки зрения продуктовых дизайн-команд 🌱
Руководитель команды продуктового дизайна и исследований Lamoda Костя Обухов выступил на UX/UI Conf. На основе опыта управления он поделился видением модели зрелости компаний и тем, как в них встраивается функция продуктового дизайна.
❗️ Модель отсылает к методологии производительности и зрелости CMMI. Она не является универсальной и не покрывает все типы компаний.
Однако исходя из опыта, описанные критерии критически влияют на найм, экспертизу, процессы и понимание роли дизайнера в командах.
➡️ Делимся разбором модели в карточках.
#La_interview
Руководитель команды продуктового дизайна и исследований Lamoda Костя Обухов выступил на UX/UI Conf. На основе опыта управления он поделился видением модели зрелости компаний и тем, как в них встраивается функция продуктового дизайна.
Однако исходя из опыта, описанные критерии критически влияют на найм, экспертизу, процессы и понимание роли дизайнера в командах.
#La_interview
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥4❤1
если ты безработный или почти, а хочешь крутую работу, то хочу порекомендовать пообщаться с Димой (это другой Дима)
работа хорошая и место знатное!
Привет!
Я Дмитрий, Tech Product трайба платформы компании mindbox.
Ищу Senior Platform Engineer.
🎯 Основная цель:
Создание инфраструктурных сервисов как продуктов для разработки, движение к IDP (Internal Developer Platform).
📊 О нас:
- 50 миллионов транзакций в день, 400+ миллионов профилей в базах, десятки миллиардов фактов, несколько тысяч подключенных касс, с доступностью 24/7.
- 9 стоек своего железа, два цода, быстро растем по 1-2 стойке в год.
- 40 000+ ядер в Yandex.Cloud, входим в TOP10 клиентов.
🛠️ Стек::
- Kubernetes в Yandex.Cloud , а также на своем железе на Deckhouse с поддержкой от Flant
- Terraform + Ansible + Packer (переходим на Crossplane)
- с GitHub мигрируем на GitLab
- Gitlab + OctopusDeploy + Helmfile
- Prometheus + VictoriaMetrics + Grafana + AlertManager + GrafanaOnCall
- MS SQL мигрируем на PostgreSQL
- Kafka, Cassandra, Clickhouse, Redis, RabbitMQ, Mongo
- Graylog (1Tb логов в день) + Sentry + Loki
- Виртуализация HyperV (мигрируем на Proxmox)
- Other: Teleport,skupper,vault,ChaosMesh & etc
Если тебе интересна эта вакансия, то го к нам на собес :)
Мой контакт в Telegram: @impel1o
─────────────────────
P.S. Плюшки:
🎓 Well-being программы: 350 000 ₽ в год на образование, медицину, спорт и путешествия
🏡 Удаленка (но есть и отличные офисы в Москве и Ереване)
💻 Техника: MacBook, мониторы, наушники и другое
🏢 Работа в аккредитованной IT-компании
🎉 Корпоративная жизнь: тимбилдинги, квесты, спортивные мероприятия
работа хорошая и место знатное!
Привет!
Я Дмитрий, Tech Product трайба платформы компании mindbox.
Ищу Senior Platform Engineer.
🎯 Основная цель:
Создание инфраструктурных сервисов как продуктов для разработки, движение к IDP (Internal Developer Platform).
📊 О нас:
- 50 миллионов транзакций в день, 400+ миллионов профилей в базах, десятки миллиардов фактов, несколько тысяч подключенных касс, с доступностью 24/7.
- 9 стоек своего железа, два цода, быстро растем по 1-2 стойке в год.
- 40 000+ ядер в Yandex.Cloud, входим в TOP10 клиентов.
🛠️ Стек::
- Kubernetes в Yandex.Cloud , а также на своем железе на Deckhouse с поддержкой от Flant
- Terraform + Ansible + Packer (переходим на Crossplane)
- с GitHub мигрируем на GitLab
- Gitlab + OctopusDeploy + Helmfile
- Prometheus + VictoriaMetrics + Grafana + AlertManager + GrafanaOnCall
- MS SQL мигрируем на PostgreSQL
- Kafka, Cassandra, Clickhouse, Redis, RabbitMQ, Mongo
- Graylog (1Tb логов в день) + Sentry + Loki
- Виртуализация HyperV (мигрируем на Proxmox)
- Other: Teleport,skupper,vault,ChaosMesh & etc
Если тебе интересна эта вакансия, то го к нам на собес :)
Мой контакт в Telegram: @impel1o
─────────────────────
P.S. Плюшки:
🎓 Well-being программы: 350 000 ₽ в год на образование, медицину, спорт и путешествия
🏡 Удаленка (но есть и отличные офисы в Москве и Ереване)
💻 Техника: MacBook, мониторы, наушники и другое
🏢 Работа в аккредитованной IT-компании
🎉 Корпоративная жизнь: тимбилдинги, квесты, спортивные мероприятия
усложнять простое
часто стал встречать что простые вещи люди делают сложными просто потому что "я так всегда делаю и мне привычно"
с одной стороны — KISS (keep it simple, stupid) и нужно всё делать максимально просто. берешь ты воркфлоу или бизнес-процесс — не усложняй, начни с базовых простых блоков "начало" и "конец", соедини их максимально прямо, чтобы приходить к результату.
пример: задача может быть в бэклоге (статус "открыта"), когда до нее доходит исполнитель — переходит в статус "в работе", а по итогу — в статус "готово".
может быть, для прозрачности, стоит добавить что задача "зависла" (ожидает автора или какой-то другой задачи) или "готова к приемке" (если у вас приемка не прописана в DoD и требует участия заказчика)
когда я вижу воркфлоу из ветвей в 10 статусов в каждой ветке и автоматизацией на пять кнопок — мне становится плохо и я хочу посмотреть в глаза тем оптимизаторам, что это городят.
однако, с другой стороны — у каждой усложненной процедуры есть история. зачастую она базируется на использовании одного инструмента разными командами.
такие случаи можно решать через общие правила, либо разделение тех самых флоу по командам/проектам.
это касается не только задач и их флоу в трекерах, это может касаться любой сферы.
усложнение нужно только тогда, когда оно действительно дает большУю (и бОльшую) прозрачность и одновременно ускоряет работу. в других случаях — мы стремимся все формализовать, тем самым ставя себе ловушки по пути.
и еще одно: если вас надо всегда вести за руку — просто уходите из инженерии, займитесь другими делами, вам будет сильно легче.
часто стал встречать что простые вещи люди делают сложными просто потому что "я так всегда делаю и мне привычно"
с одной стороны — KISS (keep it simple, stupid) и нужно всё делать максимально просто. берешь ты воркфлоу или бизнес-процесс — не усложняй, начни с базовых простых блоков "начало" и "конец", соедини их максимально прямо, чтобы приходить к результату.
пример: задача может быть в бэклоге (статус "открыта"), когда до нее доходит исполнитель — переходит в статус "в работе", а по итогу — в статус "готово".
может быть, для прозрачности, стоит добавить что задача "зависла" (ожидает автора или какой-то другой задачи) или "готова к приемке" (если у вас приемка не прописана в DoD и требует участия заказчика)
когда я вижу воркфлоу из ветвей в 10 статусов в каждой ветке и автоматизацией на пять кнопок — мне становится плохо и я хочу посмотреть в глаза тем оптимизаторам, что это городят.
однако, с другой стороны — у каждой усложненной процедуры есть история. зачастую она базируется на использовании одного инструмента разными командами.
такие случаи можно решать через общие правила, либо разделение тех самых флоу по командам/проектам.
это касается не только задач и их флоу в трекерах, это может касаться любой сферы.
усложнение нужно только тогда, когда оно действительно дает большУю (и бОльшую) прозрачность и одновременно ускоряет работу. в других случаях — мы стремимся все формализовать, тем самым ставя себе ловушки по пути.
и еще одно: если вас надо всегда вести за руку — просто уходите из инженерии, займитесь другими делами, вам будет сильно легче.
💯6