Кто лучше делает, у того и проблемы

Сегодня будет странное контринтуитивное размышление с непонятными выводами 🙂

Тезис
Кто хорошо работает, у того забот намного больше.

Пример
Когда я проходил срочную службу в армии, я видел разные стратегии избегания работы. Это называлось «зашариться». Не буду рассматривать нерелевантную банальщину типа «спрятаться с глаз долой».
Подходит под нашу сегодняшнюю тему способ избегания работы – выполнять работу плохо, косить под дурачка.
Люди специально косили под тех, кто плохо понимает, не умеет делать базовые простые вещи, вплоть до того, что якобы не умеют читать.

Кого попросят сделать работу? Дурачка, который читать не умеет и уже два раза плохо сделал, или нормальному парню, который уже два раза хорошо сделал?

В итоге больше работали те, кто делал работу хорошо. Это комментировалось фольклорной фразой «кто не шарит, тот х**рит».

А что там в работе?
Недавно читал статью, которая рассказывает, что нельзя судить менеджеров проектов по статистике успешных и заваленных проектов. Ведь может оказаться так, что хорошим менеджерам выдают очень сложные, мутные, проблемные проекты, а плохим – легкие. А в результате метрика как будто у всех на одном уровне примерно.

Есть у меня знакомые, которые так стараются сделать всё идеально, что отдают все силы и время на это. В результате обычно им подваливают еще проектов/задач/команд. А кто на расслабоне делал просто средненько, обычно и дальше не бывает в завале.

«Минимальная» сторона
Даже в айтишечке, которая гордится своими быстрыми темпами и успешными успехами, всё чаще проявляется субкультура «минимальщиков».

Идея такая: «делать минимальную работу, чтобы не уволили» и при этом не упарываться. Больше оставлять времени «для себя». Кажется, что таким людям и правда дофига задач подкидывать не будут, зная их темпы. Повышения не видать, но так и в целом платят неплохо же.

У меня даже недавно знакомый спросил: «А есть возможность от грейдапа отказаться, если предложат?» 🙂

Как правильно?
Я не знаю, как правильно. Наверное, нет тут единственно истинного «правильно». Для себя решил, что мне не подходит минимальный вариант (я пробовал). Не могу я сознательно забивать и недоделывать в том, что мне искренне интересно.
Но, правда, и не хочется, чтобы это эксплуатировалось со стороны генератора задач. Тут лично я за разумный баланс.

Итог
Есть стратегия, как можно мало работать. Прям работающая стратегия. Каждый для себя сам должен решить, насколько она ему подходит.
Ну и очень хочется верить, что руководители тех, кто готов много и хорошо работать, не будут это сильно эксплуатировать. Несколько раз видел, как это приводило или к увольнению, или к демотивированному переходу в стан «минимальщиков».

Я принес. Планирование через боль

Один из моих постоянных читателей и комментаторов, Никита Ульшин, ведет свой телеграм-канал.
Вчера, пока ждал свой самолет, чтобы улететь из чудесной Казани, я прочитал в его канале серию заметок про планирование и понял, что точно её стоит принести сегодня.

⁃ Первая часть рассказывает, почему не работает бездумное умножение на коэффициент https://news.1rj.ru/str/ulshinblog/309
⁃ Вторая часть про риски https://news.1rj.ru/str/ulshinblog/310
⁃ Третья, особенно полюбившаяся мне, про метод рационального фланера https://news.1rj.ru/str/ulshinblog/311 Сам примерно так же действую и очень удивляюсь, когда люди планируют вперед на полгода-год и прямо не оставляют себе никаких возможностей для изменения планов. Даже если выясняется, что план был так себе и продукт получается так себе, всё равно тянут эту лямку, потому что «ЗАПЛАНИРОВАНО ЖЕ!».
⁃ Ну и четвертая часть про выводы, дополнительные техника (типа вероятностного распределения) и список полезной и интересной литературы https://news.1rj.ru/str/ulshinblog/312

На мой взгляд, это те самые 20% усилий в планировании, которые принесут 80% результата.

Люди выбирают не первых и лучших, а своих

Недавно читал книгу «Всё закончится, а ты нет» и встретил там фразу «Люди выбирают не первых и лучших, а своих».

Мне кажется, если в это глубоко вдуматься, понять и принять, то отпадут некоторые страдания от собственной неидеальности.

В чем проблема?
У тимлидов много разных направлений: проекты, люди, техника. По каждому направлению всегда море задач. Всё успеть, да ещё и хорошо – просто нереально.
Начинаешь чем-то жертвовать: где-то задачу не сделал совсем, где-то что-то забыл, где-то уголок срезал, чтобы впихнуть невпихуемое, и уже чувствуешь, что по многим фронтам как будто бы плохо всё.

В бытовой жизни примерно та же история. Где-то ты на рутинные вещи подзабил, где-то семье мало времени уделил, где-то коришь себя за то, что не успеваешь заниматься хобби или ленишься ходить в театр, например.

И вот получается, что общее настроение такое, что и там, и тут что-то постоянно недотягиваешь и вообще «кому я, нафиг, такой нужен?»

В чем суть ключевой фразы?
На мой взгляд, какими бы «недостаточно хорошими» мы себя ни ощущали, нас же кто-то выбирает. На работу взяли, фидбэк о работе дают не самый ужасный, с позором взашей не увольняют, а у кого-то есть партнер, который также совершил сознательный выбор.
Почему так?
А потому, что выбирают не самого идеального, а своего.

Одна команда принимает тимлида, который душевную атмосферу внутри создает, другая – того, что держит заказчиков и техдолг в ежовых рукавицах, третья – только супер лютого технаря, который может научить величайшим сложнейшим премудростям.

В романтических отношениях похожая история. Зачастую выбирают не самого богатого/высоко/красивого, а того, с кем будет персонально комфортно, уютно, безопасно.

Вспомните сами каких-нибудь мастеров/тренеров/репетитиров, чьими услугами вы пользуетесь регулярно. Там же не лучшие из лучших, только топовые небожители. Там те, кто делает «достаточно хорошо» и при этом вам персонально подходит. «Ваш» человек, одним словом.

Что это значит?
Это значит, что необязательно себя корить за неидеальность во всех аспектах жизни и работы. Если вы делаете «достаточно хорошо», то обязательно для вас найдется местечко, где вы будете «своим». И там вам будет хорошо.
А даже если и «недостаточно хорошо» делаете, то по-любому тоже что-то подвернется, только с более низким качеством, так сказать.

Итог
Хочется пожелать вам и себе перестать гнобить себя за малейшие неидеальности и посоветовать хорошо подумать, что/кого вы чувствуете «своим» и где бы вас так воспринимали. Порефлексировать и стремиться туда, где будет комфортно и не будет осуждения за малейшие огрехи.

Я принес. Немного своих анонсов

Сейчас у многих выходные, но если ты – завсегдатай всяких конференций, подкастов, вебинаров и всего такого прочего, то часть выходных тратится на подготовку.
Так как я в разгаре подготовки, а многие из вас в разгаре отдыха, я решил сегодня не слать сюда чего-то такого, что прямо сейчас надо читать, смотреть, слушать, переваривать.

Я поделюсь с вами ближайшими анонсами того, над чем я сейчас работаю.

1. 15 мая сессия для Podlodka Soft Skills на тему того, что надо спрашивать работодателей при трудоустройстве. Эдакое публичное собеседование наоборот. Посмотреть описание можно тут https://podlodka.io/softcrew
2. 25 мая буду докладывать на родине своих родителей, в Новосибирске, на Codefest про разные вариации тимлидов: когда какие нужны, какими навыками должны обладать и как самим, меняя работу (а можно и не меняя), это знание использовать с толком. Описание тут https://14.codefest.ru/lecture/2484
3. Ну и продолжаю трудиться над подкастами «Кода кода» (выбрали темы, гостей, и вот-вот начнем записывать первые выпуски нового сезона) и «Три тимлида заходят в бар» (релизнули только один выпуск, но записали на самом деле про запас уже несколько).

Буду рад встречам с вами в онлайне и в офлайне.

Три тимлида зашли в бар (созвонились), чтобы поговорить о бесконечных созвонах

Невозможно было обойти стороной тему созвонов / встреч / митингов / синков и прочего, что можно называть как угодно, но суть остается всё та же :)
Тема эта прям сильно болит у тимлидов, менеджеров и прочих сочувствующих, но бывают команды, где у каждого разработчика тоже может быть по несколько созвонов в день каждый день.

Надеюсь, наше бухтение, лайфхаки и прибаутки по этой теме будут интересны и полезны.

Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут

Приятного прослушивания! Заносите в комментарии свои лайфхаки борьбы с бесчисленным множеством созвонов.

Не знаешь? Пиши доку

Когда-то я делал доклад про онбординг и там озвучивал капитанскую мысль: надо стараться по максимуму прикладывать силы новичков к генерации документации.

В чем смысл
Вы работаете в вашем проекте довольно давно. У вас есть много контекста и замыленный глаз. Когда новичок приходит в проект, ничего о нем не зная, и читает имеющуюся доку, то он очень хорошо детектит то, где непонятно или неактуально.

А еще он – представитель самой релевантной аудитории для докочитателей. Он из тех, кто не знает многих деталей и тонкостей, и идет читать доку, чтобы разобраться.

Поэтому именно он может дополнить документацию самым понятным образом.
Так что основная идея такова:
⁃ Новый человек приходит, читает. Где-то понимает, где-то не понимает.
⁃ Старшие товарищи объясняют непонятное, а он идет и дописывает.
⁃ Либо он сам разбирается и всё равно идет дописывать, ведь он же не последний приходящий сюда новичок.
⁃ Старшие товарищи подписываются на обновление документации и просто поглядывают одним глазом, чтобы там чего-то откровенно неправильного и странного не появилось.
⁃ В результате получаем регулярно пополняемую документацию на основе реальных рабочих сложностей.

Как порой бывает
Иногда я встречаю обратный подход. Люди уверены, что документацию могут писать только главные мудрецы команды.
Но разбивается обычно это о то, что главным мудрецам банально некогда доки писать, у них критические фичи горят.
А некоторым просто вломяру, ведь где небожительное написание кода, а где приземленные буковки документации (тут надо перевоспитывать)?

В итоге такие команды верят в то, что документацию написать и поддерживать некогда/невозможно.

Недавний пример
В паре команд, где я нынче менеджер, мы создавали документацию про сложный процесс, который умеют старожилы, но новички от него люто страдают.
Нашли одного инициативного старожила, который очень сильно помог побороться с проблемой чистого листа. Сгенерил базовый каркас доки, насколько смог хорошо.
А дальше новички, заходившие в этот процесс, вносили уже свои корректировки, сталкиваясь с трудностями.
Отзывы от команды были очень положительными. Особенно от тех, кто впервые заходил в этот процесс с уже более-менее готовой документацией.

А я продолжаю радоваться, периодически получая уведомления, что новые правки продолжают вноситься.

Итог
Документация нужна и важна. Её могут писать не только опытнейшие люди в команде, но и те, кто только пришел, столкнулся с непонятками и разобрался в них.
Это очень дешевый и регулярный способ пополнения и актуализации имеющейся у вас документации.

Я принес. Иногда лучше делать, а не планировать

Сегодня на повестке дня довольно спорная, на мой взгляд, статья https://habr.com/ru/companies/ruvds/articles/788920/

Статья, кстати, бешено заплюсована на хабре.

Моё личное мнение такое: в статье есть довольно инфантильно-популистская часть про то, что, грубо говоря, менеджеры не нужны, они паразиты и вообще только усложняют работу, гады такие.
Я работал и работником руками (сисадмином, разработчиком), и менеджером (тимлидом, техническим менеджером проектов), и я своими глазами видел, как без разумного менеджмента происходящего всё может пойти сильно не так, а проекты развалиться, не дожив до релиза. Так что в этом пункте я не соглашусь.

Однако соглашусь в том, что бюрократизация может выходить из разумных пределов, и люди тратят больше времени и денег на согласования формулировки одного названия или предложения, чем уже сели бы да сделали на уровне «достаточно хорошо» или даже «удовлетворительно».

Про «политику» в офисно-корпоративных историях тоже скорее соглашусь. Нередко на позициях тимлида и выше уже приходится в этом как-то хотя бы минимально участвовать, либо утыкаться в стеклянный карьерный потолок, либо и вовсе прослыть нелояльным и отправиться на мороз.

Интересно будет в комментариях прочитать ваше мнение о данной статье.

CAP-теорема тимлидов

Недавно мы с Серафимой Чекулаевой готовили контент для совместного вебинара в KOTELOV подкасте на тему взаимодействия тимлидов и продактов.
В ходе разговора Серафима сказала, что она будучи продактом, ценила в тимлидах три вещи: пипл-менеджмент, техническую компетентность и процессно-проектную деятельность. Но при этом она больше двух вещей не ожидала никогда.
Я подумал: «Черт возьми, это же CAP-теорема, но про тимлидов» 🙂

Ты чего, дед, какая теорема?
Есть такая идея, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: согласованность данных, доступность, устойчивость к фрагментации.
Ну то есть имеются три стула, на все три не сядешь, на два можно. А какие два нужны именно вам, следует подбирать по вашей ситуации.

Тимлиды
То же самое и с тимлидами. Хочется, чтобы они всё сразу умели, хотели и делали. Но в реальности полный набор навыков еще поди найди у человека, а даже если и нашел, то появляется классическая ситуация, когда 80% времени надо код писать и 80% времени заниматься менеджментом.

Так что можно проектировать нанимаемого тимлида (или себя самого, если угодно) согласно CAP-теореме для тимлидов.
Понимаем, что за команда, чего не хватает, какие уже есть люди и компетенции в команде, и недостающие вещи дотягиваем тимлидом. Эта методика хорошо разрешает вопросы типа «А вот бывает техлид и тимлид. Кто из них что делает?». Техлид будет за технику и архитектуру, а тимлид – за внутренние и внешние коммуникации, ведения проектов, организацию рабочих процессов.

Если в команде нет сильных технарей, тимлид будет покрывать техническую составляющую и на сдачу как-то поддерживать либо внутренние коммуникации между людьми, либо организацию и контроль комплексного ведения проектов, чтобы четенько, в срок, прозрачно, понятно для внешнего наблюдателя.

В общем, смысл вы, надеюсь, поняли.

А ты кто?
Я бывал в разных комбинациях. В данный момент я про людей и процессы/проекты, работаю с очень сильными технарями.

На прошлой работе был больше про разработку, а баланс между людьми и процессами варьировал в зависимости от того, что сильнее болит. Сначала болели (можно сказать, отсутствовали) процессы и занимался ими. Потом перестали болеть и я больше уделял внимание пипл-менеджменту.
Потом стало казаться, что пипл-менеджмент и процессы/проекты приносят больше глобального профита, поэтому от техники стал отходить постепенно.

Все три стула сразу
На мой взгляд, такое возможно исключительно в том случае, когда они маленькие. То есть маленькая команда (2-3 человека) и небольшой набор проектов (чтобы не рваться по разным сторонам).
Ну либо когда человек работает по 10-12 часов в день. Но тут у меня есть опасения по поводу долгосрочной перспективы, а также его мотивации и здоровья. Да и качество с такими регулярными овертаймами обычно хромает.

Итог
Забавная отсылка к оригинальной CAP-теореме заставляет задуматься: «Сам я на каких стульях сижу? А хочу на каких сидеть?».
Пишите в комментариях, на каких стульях сидите вы. А если на всех трех сразу, и у вас это замечательно получается, то делитесь секретами успеха и продуктивности!

Я принес. Что такое жизнь без работы и что такое работа после саббатикала?

Пару месяцев назад мы с коллегами делали митап в Питере на тему «Как быть счастливым на работе?».
Сегодня хочу поделиться с вами одним из докладов митапа на очень интересную тему https://www.youtube.com/watch?v=vURgYlDurxk

У многих моих знакомых идея того, чтобы долго (год и дольше) не работать, вызывает совершенно разные мнения:
⁃ Ну и правильно, от работы кони дохнут!
⁃ Я совершенно точно не могу не работать, вы чего?
⁃ Наконец-то доиграю, дочитаю, досмотрю всё накопленное.
⁃ Займусь чем-то общественно полезным.
⁃ Бизнесок свой, давно задуманный, замучу.

Мнения представлять можно разные, но мало кто реально в такой долгосрочный саббатикал ходил. А тут вот можно послушать реальную историю.

Лично для меня в этой истории почему-то очень ярко отложилось то, как у докладчика изменился уровень потребления.

Когда перерабатывал, то потреблял больше и дороже, как бы награждая себя за это своё старание и страдание. А когда перестал в этой суете крутиться, успокоился, то отказалось этого всего и не надо уже.

А был ли у вас опыт, когда вы полгода-год не работали? Что делали? Как впечатления? А если бы сейчас так можно было, чем бы занялись?

Перформанс ревью. Плюсы, минусы, подводные камни

В этом выпуске мы поговорили на животрепещущую для бигтехов тему – перформанс ревью.
Вокруг этого процесса куча споров. Много и сторонников, и противников.
Тем не менее, это практически стандартная процедура для многих крупных компаний, так что разбираться точно надо.

Я специально постарался поднакинуть для драматизма, но мои товарищи неплохо это всё отбили :)

Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.

Приятного прослушивания!

Приносите в комментарии свою трактовку плюсов и минусов ревью. Всегда интересно узнавать чужой опыт и мысли.

Крыша потекла

Сегодня мой пост будет основываться на картинке, в которой многие из нас могут узнать себя.

Крыша прохудилась, но Хаггис её не чинит. В дождь слишком мокро, чтобы работать, а в солнечную погоду дыра в крыше не так уж и беспокоит.

Техдолг, рефакторинг и улучшалки
Когда мы в разгаре производства крупных фичей или приближающихся дедлайнов, наступаем на какие-то грабли, которые клятвенно обещаем себе поправить потом, когда гореть перестанет.

Но случаются релизы, шумные и расслабленные выдохи, и мы говорим себе: «Ну вроде как-то и так прожили. Щас бы отдохнуть. Может, потом уже и не пригодится это». И не делаем. А потом колесо сансары делает свой оборот, и всё начинается заново.

Причем этим страдают и менеджеры, и инженеры.

Что делать?
У меня на многое один ответ – дисциплина. Это вы уже могли понять по тому, как я пятый год каждую пятницу без пропусков посты делаю 🙂

Если вы точно знаете, что делать надо, но малодушно не делаете, потому что «чет неохота сейчас», «мне бы что-то поинтереснее», «да может, пронесет в следующий раз», то тут хорошо работает бэклог, напоминалки, дедлайны и вообще планирование, чтобы не плыть просто по течению и желанию левой пятки.

Другое дело, что надо и правда быть уверенным, что что-то делать надо. В пылу задач и проблем вам может что-то показаться, вас триггернуло и про это завели задачу. Но потом с уже остывшей головой и другими частями тела лучше бы менее эмоционально к этому вернуться и понять, а точно ли оно нужно. Сделать дополнительный подход валидации.

Например
Был у меня случай, когда требовалось на куче серверов не самым легким образом ПО обновить, но было некогда, мы пилили новые фичи и страдали. Однако когда крупный релиз был закончен, мы всё же обновились, и это оказалось не зря, потому что дальше пошел разгар другого проекта, начали появляться в публичном поле всякие критические уязвимости. Если бы мы не обновились в межсезонье, то пришлось бы в горячий сезон ставить всё на стоп и обновляться.

А был обратный пример, когда разок наткнулись на проблему, нашли обходной путь, фичу запилили. Но инженерное негодование вскипело, решили делать большой рефакторинг. Делали-делали, а оказалось, что проектом заниматься некому, он заморожен, и вообще впустую время потратили.

Итог
Дисциплина помогает делать то, что надо делать, а не только то, что хочется делать.
Но должна быть и рациональная переоценка после того, как эмоционально пригорело, чтобы не сделать лишнего.

Попугай-менеджмент

Многие знают про чайка-менеджмент – это когда прилетел, покричал, навалил кучу… задач и улетел.

А попугай-менеджмент – это отсылка к распространенному анекдоту про то, что попугай научился говорить: «Какой статус по этой задаче?» – и стал ПМом (проектным менеджером).

И вроде ха-ха, дурацкая и легкая работенка, ходить и всех задалбывать этими вопросами. Но не всё так просто.

На работе
Конечно, мы сейчас выносим за скобки планирование, менеджмент процессов, приоритизацию, слаженную работу между апстримом и даунстримом, риск-менеджмент и прочее. Просто говорим про работу попугаем.

Так вот, когда я был тимлидом одной команды и в её задачах варился, я смеялся над этим анекдотом и плакал от смеха. Но чем больше становилось у меня команд, чем больше становилось таких проектов, где затронуто много внешних команд, тем больше я стал плакать не от смеха, а от жизы.

Иногда и правда бывает, что крутые специалисты делают сложные вещи, но как только дело касается обязательств и коннекта со смежниками, там может случиться ступор, забывчивость, рассинхрон и прочее.
И вот летаешь как попугай и говоришь: «Вы тут до финального решения договорились? Нет? Ну тогда договоритесь». И так несколько итераций, пока договора не случится.

Это нудно, но порой необходимо, чтобы что-то хорошее всё же в итоге случилось. Так что ничего зазорного в этом нет.

Смотрел недавно одно видео, где девушка, проработавшая 10 лет в «Маккинзи», а ныне СЕО клиник «Скандинавия», рассказывала, что у неё есть принцип семи раз. То есть семь раз надо повторить одно и то же, чтобы из ничего случилось что-то. Я её хорошо понимаю 🙂

В жизни
Я уже рассказывал, что делаю сейчас капитальный ремонт в квартире. И со строителями только попугай-менеджмент и работает (ну еще не платить денег, если они вконец оборзели, но это другая история).
Вот реально как с золотыми рыбками говоришь. Дизайн-проект дал, всё объяснил, покивали, а сделали не так. Только многократное объяснение дает хоть какое-то повышение шанса, что сделают так, как надо, а не так, как фляга просвистела.

И вот вроде не хочется таким со взрослыми людьми заниматься, но получается, что не быть попугаем – вредить себе же. Это у меня в квартире в итоге плохо будет. А строителям-то пофигу, они на другие объекты пойдут работать. Интересная корреляция с некоторым пластом айтишников (неважно, разработчиков или менеджеров) даже вырисовывается 🙂

Итог
Быть попугаем – это нудно. Грустно, что со взрослыми людьми и крутыми профессионалами так работать иногда приходится. Но кажется, что в жизни в целом так работает частенько, и не стоит надеяться, что везде будут попадаться исполнители, коллеги и друзья такие, что никогда этим заниматься не придется.

Я принес. Публичное собеседование: Как собеседовать работодателя

Недавно моя коллега и товарищ по подкасту Настя Абрашитова позвала меня провести сессию на мною любимой Podlodka Soft Skills Crew.
Тема этого сезона была про собеседования, смену работы и всё такое прочее. Сосредоточились на том, что спрашивать у работодателя на собеседованиях.
А мне вроде рассказать про это уже и нечего. Статью на Хабре писал, в круглом столе тимлидской подлодке версию для тимлидов тоже уже предлагал. Однако мы вспомнили, что сейчас в моде публичные собеседования)

В итоге я заготовил вопросов на роль бэкендера, а Настя заготовила образ мутного работодателя, из которого надо было эту мутноту выспросить. Расставила там ловушки и пасхалки. Большинство я нашел, но немного и пропустил.
Мне кажется, было и забавно, и поучительно.

Напоминаю, что на собеседованиях вы тоже можете и должны задавать вопросы работодателю, и эти вопросы надо подготовить. Надеюсь, данное видео и сопроводительные ссылки в описании вам помогут в этом деле.

https://www.youtube.com/watch?v=x-duHH6AIQk

Три тимлида заходят в бар и обсуждают дружбу на работе

В кругах тимлидов и прочих руководителей вечно ходят споры про то, насколько можно и нужно дружить с теми, кто находится под твоим руководством.

Тема эта неоднозначная, и, лично мне кажется, что ответы на неё будут ощутимо разные в зависимости от твоей высоты и иерархии.
То есть будет ощутимая разница между тимлидом и мидл-менеджером.

Послушав наш сегодняшний выпуск, вы в некоторой мере сможете в этом убедиться, ведь у нас есть и мидл-менеджеры, и тимлид+, так я себя назову по совокупности причин.

А еще вы узнаете: как ведущие подкаста сохраняют товарищеские отношения, находясь в рабочих отношениях, в чем заключается принцип шашлык-лидершип и прочее интересное.

Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут.

Приятного прослушивания!
Рассказывайте в комментариях, насколько дружны или формалистичный ваши отношения с коллегами.

Алгоритмизация: время- и нервосбережение

Раньше, когда нам с женой надо было куда-то полететь/поехать на несколько дней/недель, приходилось очень много времени тратить на подготовку. Долго собирались, могли что-то забыть, постоянно были в нервном напряжении, гоняя в голове то, что могли упустить.

Теперь же мы стали это делать намного быстрее и намного спокойнее. В последние разы даже собрались настолько быстро, что первое время относились с подозрением. Это как, когда код написал, а он сразу заработал и все тесты прошли:)

Как так?
Заколебались при сборах каждый раз начинать с нуля и придумали инструкцию/чеклист, что нужно собрать из вещей, что нужно иметь в дорожной аптечке, что проверить на выключенность перед выходом из дома (привет соседям, заливающим и оставляющим без воды других, пока отдыхают на даче без связи).

Чем это еще хорошо?
Недавно где-то читал, как подобная алгоритмизация способствует душевному спокойствию.
Не надо сталкиваться с неопределенностью, испытывать из-за этого тревогу, заниматься бесконечной хаотичной перепроверкой. Всё максимально детерминировано. Знай себе проходись по всем пунктам, а дальше занимайся спокойно своими делами.
Лично я с этим очень согласен. Для мутных вещей с множеством мелочей алгоритмизация меня сильно успокаивает.

А в работе как у меня?
Мне кажется, что я со своей методикой постепенной регулярной работы тоже пытаюсь добавить себе спокойствия в этом хаосе.
Я ежедневно откусываю небольшой кусочек от нужного направления и спокойно живу дальше, зная, что каждый день я потихоньку это буду делать и какого-то приемлемого результата добьюсь.

Лично мне так намного спокойнее, чем то наскоком делать, то окукливаться после спурта, то прокрастинировать в надежде на последний момент.

Так это ж всё очевидно!
Я иногда выныриваю из айтишного пузыря, где множество начитанных про успешный успех, тайм-менеджмент и 87 навыков высокоэффективных людей. И если в нашем пузыре никого не удивишь базовыми чеклистами, тудушными инструментами и всем таким, то снаружи вижу всякое: лютейшие откровения про то, что можно вести список дел и перестать забывать, или ставить уведомлялки-напоминалки на конкретное время, или писать инструкции для коллег, чтобы они сделали то, что надо, а не то, что боженька на душу положит.

Это я не к тому, что айтишники какие-то небожители. И у нас хватает разгильдяев, и снаружи хватает организованных. А к тому, что очевидные простецкие штуки для вас могут оказаться полезными для некоторых ваших товарищей и близких. Так что не стесняйтесь делиться, и не думайте, что если вам это очевидно, то и другим будет очевидно тоже.

Итог
Алгоритмы и чеклисты сильно экономят время и нервы, являются небольшими островками душевного спокойствия и безопасности.
Делитесь со своими товарищами очевидными полезностями, ведь может оказаться, что для них это неочевидно.

Поделитесь в комментариях своим опытом использования инструкций и чеклистов для быта или работы, которые вам сильно помогают. Хочется чего-то интересного для себя на ус намотать.

Я принес. Продуктивный инженер

Сегодня я вам принес выпуск подкаста DevZen, в котором очень интересно ребята обсуждают, как быть продуктивным, у кого какие привычки, лайфхаки и особенности для комфортной работы.

Я послушал полтора часа за один присест. Очень жизненная получилась дискуссия.

Не скажу, что я прям что-то новое для себя узнал. Скорее узнал подтверждения тому, что мои привычки и лайфхаки, которые я для себя вырабатывал за 17 лет в ИТ, оказались довольно схожи с мнением ребят.
Ну и в целом я довольно много таких материалов анализирую. Так что то, что мне может оказаться известным, кому-то, не так сильно интересующемуся, может и зайти в новинку, так что послушайте.

А если даже там для вас ничего нового не будет, то всё равно сложится приятное ощущение, что какую-то жизненную жизу обсудил в кругу единомышленников.

Ссылка
https://devzen.ru/episode-466/

Тимлиды, разбор кейсов и подкасты

Всё это обсудили с товарищами из KOTELOV подкаста. Вообще очень много тем собрали и так интересно было беседовать, что получился долгий выпуск.

Признаюсь честно, обсудить мы хотели ещё больше, но это уже было за гранью разумного по таймингу🙂

Я много раз записывался в разных подкастах и сам веду парочку, но обычно это всё удаленно.
А тут у ребят оказалась студия для записи в Питере, поэтому записались очно и вышли в ютубе.

В который раз убеждаюсь, что такой формат делает разговор живее и привычнее нам для восприятия. Но и сложностей для производства хватает.

Описание и ссылки на выпуск тут https://news.1rj.ru/str/kotelov_love/904

Трудоемкость != сроки

Недавно видел один доклад, где в шуточной форме рассказывалась жизненная история о том, что разработчики стараются максимально обтекаемо говорить о трудоемкости задачи, чтобы ни в коем случае не закоммититься на сроки.
Шутка, как говорится, смешная, а ситуация страшная. И актуальная.

И в данном посте, раз уж канал больше про менеджмент, я бы хотел обсудить недопонимание трудоемкости и сроков со стороны менеджеров/заказчиков.

Сколько нужно времени, чтобы это сделать?
Спросите вы у разработчика. И мы сейчас скипнем ситуацию (потому что в пост не влезет), когда он скажет: «Я не знаю, я этого ни разу не делал», или «Тут всё так сложно, что мы одно чиним, другое ломается», или «За день точно сделаю», а по факту безвылазно будет делать только эту задачу всю неделю.

Представим, вам ответили: «За один день можно сделать». И дальше в этот момент некоторые менеджеры или заказчики начинают ошибочно думать, что задача будет готова завтра. И вот этот один день отсчитывается с данного момента.

Но ведь это в корне не верно. Трудоемкость может быть и один день, но, возможно, сейчас человек делает другую важную задачу и не может отвлечься, или завтра он уходит в отпуск, заболевает, командируется, увольняется. Следовательно, сроки начала сдвигаются, а вот про них никто в моем примере не спросил.

Пример из жизни
Как-то мне довелось быть тимлидом в команде, где на 5 человек было 12–15 проектных направлений. И там такое недопонимание доставляло много боли.

Каждый заказчик каждого направления считал, что уж он-то важнее всего и его задачу мы готовы начинать прямо сейчас, а остальной десяток подождет. И по факту оценка трудоемкости, конечно, никак не коррелировала со сроками поставки.

Пришлось очень много времени потратить, чтобы люди поняли, что они не одни в вакууме, что команда делает сразу много по всем фронтам, что приоритеты и планы вот такие, а если хотите побыстрее, то деритес давайте договариваться.

Особо печально, когда менеджеры, которые вроде как должны эти простейшие вещи понимать, может, их и понимают, но не принимают. Ну не хотят люди вот этих вот каких-то сложностей, не хотят принимать, что есть кто-то страждущий, кроме них, есть другие приоритеты, кроме их планов на квартал, а хотят просто магии. Хотят волшебства, чтобы вжух – и у них всё появилось, а у других хоть трава не расти. Как вы будете делать – не волнует. Можно ли так вообще физически сделать – тоже не волнует.

Не надо так.

Итог
Оценка трудоемкости – это совершенно не одно и то же, что прогноз сроков поставки. Вы должны понимать, что и зачем вы спрашиваете, чтобы правильно интерпретировать ответы, самим потом не разочаровываться и других не заколебывать.

А еще так в жизни случается, что каждый сам кузнец своего счастья. Так что, если вам даже назвали трудоемкость, время старта работ, прогноз по срокам, и для вас это что-то очень важное, то постарайтесь вместе с исполнителями разобраться, нет ли чего-то, вносящего риски срыва сроков: завязка на смежные команды, плохо работающего или выгоревшего сотрудника, высокую неопределенность реализации и прочее.

Я принес. Так много тимлидов хороших и разных. А я какой?

Как я уже писал ранее, я в этом году помогал в организации менеджерского трека на конференции Codefest.

Но помимо организационных вопросов, мне удалось выступить там с докладом.

Мне очень радостно от ламповости аудитории на конференции, от количества присутствовавших людей и желающих обсудить разные вопросы после доклада.
Признаться честно, именно эта душевная и ламповая атмосфера и стала для меня одним из решающих факторов для участия в ПК.

Про что доклад?
Доклад про разновидности тимлидов и разные ситуации в команде и компании.
О том, как это всё матчится друг с другом и почему частая вакансия играющего тренера, который 80% времени пишет код и 80% занимается менеджментом, не приносит ничего хорошего ни самим тимлидам, ни компаниям.

Постарался предложить, как, где и когда можно порезать скоуп или качество, чтобы не пытаться впихивать невпихуемое и работать эффективно и счастливо.

Вопросы после доклада тоже мне очень понравились: многое было точно подмечено, разумно предложено и жизненно сформулировано.

Рад был со многими лично увидеться повторно или познакомиться впервые.

Ссылка
https://www.youtube.com/watch?v=vr4MhKiar5s