Несколько заметок из линкадина, чтобы не потерять.
Разрешайте программистам проёбываться
Важная мысль. Разрешайте программистам проёбываться.
Иногда для того, чтобы решить нетривиальную задачу, надо переключиться и какое-то время её не решать, ничего не гуглить и ни с кем её не обсуждать. На первый взгляд, звучит странно, но работает.
Со мной в студенчестве была ситуация. У меня не ладилось с дискретной математикой. Нужно было сдать ещё несколько расчётно-графических работ, чтобы быть допущенным к экзамену, а потом ещё и сдать этот самый экзамен, а у меня не получалось, время начало поджимать.
И тут один друг предложил отправиться в трёхдневную поездку в Польшу (в Калининграде это нормально) и я согласился. Быстренько сделал визу, собрал небольшой набор вещей на три дня, выкинул из головы дискретку, сел с группой в автобус и поехал. И в поездке не думал ни про числа компонент связности, ни про алгоритмы Дийкстры и Краскала, ни про комбинаторику, ни про гладкости, ни про что. Просто переключился и выдохнул.
Ночью воскресенья прибыл в Калининград, дошёл до своей общаги, лёг спать, выспался, а потом написал все недостающие РГР-ки, сдал экзамен на «хор» и навсегда усвоил, что иногда надо переключаться.
Я знаю, что мои программисты, аналитики и тестеры могут иногда вместо работы просидеть полдня на морском берегу или сходить с девушкой на киносеанс и никогда их в это не тыкаю и не наказываю, так как знаю, что благодаря переключению решить поставленную задачу будет намного проще.
* * *
Как казаться умным
Парадокс в том, что казаться умным нетрудно — нужно лишь говорить людям то, что они хотят слышать, но чтобы знать, что они хотят слышать, надо быть умным.
* * *
О важности «нет»
Каждый раз, когда я говорю «нет», чувствую себя немного мудаком. Видимо, это тянется из детства, из взаимоотношений с родителями. Если мама о чём-то просит, надо согласиться и сделать, иначе ты плохой ребёнок.
А в реальной практике менеджера проектов говорить «нет» приходится постоянно.
Аналитики проработали задачу, потратили десять-пятнадцать часов, но рынок изменился, она не нужна. Нет, мы не будем её реализовывать. Но как же жалко, люди работали, вот я мудак.
Пообщался с пятерыми подрядчиками для нетипичной доработки, выбрал одного, остальным надо сказать «нет». Блин, но люди же потратили на меня время, сделали оценку, а я такой мудак.
Провёл собеседование с кандидатом во фронтендеры, вроде, нормальный, но есть сомнения. Дал тестовое, он его неделю пилил и сделал ну прямо плохо. Рецензент говорит, человек совершенно не понимает современные тренды фронтенда, его надо полгода дообучать. Но как же жалко, мы потратили время на собеседование, он потратил время на тестовое, а надо сказать «нет», вот я мудак.
Вы не мудак, говорить «нет» нужно, иначе ничего у вас не выйдет. И контрагенты, которым приходится отказывать — не ваша мама, они не обидятся, а будут искать другие возможности.
* * *
Стой, раз, два
Специалисты Красного Креста в начале обучения спрашивают, какое должно быть первое действие при оказании первой помощи. И это действие — не проверка пульса и даже не дыхательных путей. Это действие называется «стой, раз, два». Буквально, остановиться и пять секунд подумать.
Это простое правило позволяет избежать ситуаций, когда вместо одного пострадавшего пострадавшего образуется два.
В бизнесе тоже есть «стой, раз, два». Так называемое правило трёх часов. Если у вас случилась чрезвычайная ситуация, перед тем, как орать, грозить виновным увольнением и махать шашкой, три часа подумать. Помогает избежать огромного количества негатива и ненужных увольнений. Даже если проблема не организационная, а упавший прод, нужно сначала остановить и подумать и только потом лезть его поднимать.
Для кого-то три часа — это много и он успевает успокоиться и принять взвешенное решение за сорок минут, но в целом концепция одна. Стой, раз, два.
* * *
Проектные и процессные люди
Среди не слишком квалифицированных руководителей бытует мнение, что люди бывают, ориентированные на результат и на процесс. Первые добиваются целей, вторые просиживают штаны. Это всё херня.
Люди бывают проектные и, действительно, процессные. Проектные ориентированы на нестандартные задачи, в результате которых получается сколько-нибудь новый продукт. Проектного можно попросить открыть филиал в тайге или придумать десять синонимов к слову «мну», он сделает оценку, составит план, обоснует бюджет, состав команды и решит задачу. Процессные люди соблюдают инструкции, выполняя рутинные вещи.
Я не утверждаю, что процессные люди — существа второго сорта, наоборот, в компании нужны люди, рутинно заказывающие в офис воду и ручки с блокнотами, организующие влажную уборку, считающие и начисляющие зарплату, развозящие иногородних по домам, ведущие кадровый документооборот. От этих людей зависит нормальное функционирование компании, без них никак невозможно.
В большинстве случаев, если вы обратитесь к процессному человеку со стандартной, но несколько усложнённой задачей, всё будет нормально. Он закажет дополнительную бутылку воды, устранит засор в группе унитазов, правильно посчитает и начислит внеочередную премию, развезёт людей по домам на час позже\раньше, внесёт нестандартную запись в трудовую.
Но святые шестерёнки, какая стена вас ждёт, если по какой-то причине вам понадобится получить от процессного человека манипуляцию, хотя бы чуть-чуть вылезающую за пределы его инструкции! Если он от природы отзывчивый, вы получите целую волну искреннего непонимания, но проблему, пусть и очень небыстро, решите. Но чаще всего, эту самую копеечную, но нестандартную проблему вам придётся решать с его руководителем или вообще, плюнуть и сделать всё самому.
* * *
Стратегическое планирование
В самом начале «Мастера и Маргариты» Воланд говорит, что для того, чтобы эффективно управлять человечеством, нужно иметь точный план на какой-нибудь серьёзный срок, лет хотя бы на тысячу. И это очень правильные слова.
Предположим, вы выросли в руководители с самого низа и глубоко осознали, что большинство проблем должно решаться на нижних уровнях иерархии с кратным уменьшением количества и ростом важности решаемых проблем с каждым новым уровнем. Осознали, что подчинённые должны сами себе писать операционные планы на короткий срок, а вы их только рецензировать и править.
И тут вы можете прийти к выводу, что дело сделано. Вверенный коллектив управляем, а ваша задача теперь — следить за тем, чтобы у всех была работа, устранять блокировки и ограничения. Нет, этого недостаточно. Ваша главная задача как руководителя — держать в голове стратегические цели подразделения или компании и транслировать подчинённым приоритеты для того, чтобы эти цели достигались. Только тогда от вашей деятельности будет ощутимая польза.
Если вы хотите узнать, хороший это руководитель или плохой, спросите у него, какие стратегические цели вверенного подразделения и если он ответит, что они просто стараются качественно выполнять свои обязанности, это плохой руководитель.
* * *
Уменьшение количества багов
Возможна ли программа без багов? А возможен ли баг без программы? Хлопок одной ладонью, вход в заставу-без-ворот и другие коаны современной разработки. Баги есть всегда и есть хорошая практика, которая позволяет немного уменьшить их количество.
Практика заключается в том, что тимлид или прожект раз в месяц собирается с каждым разработчиком (лучше индивидуально) и проходится по всем багам, которые тестеры зарегали на его доработки. Выясняем причины каждого бага. Плохое ТЗ, невнимательность при разработке, функциональность сломана другой доработкой и отловлена регрессом и проч. Проговариваем, что делать, чтобы таких багов не возникало. Итоговые данные заносим в табличку.
Практика простая, но при её регулярном применении количество дефектов уменьшается.
* * *
Рассылка об увольняющихся
А вот ещё как бывает, особенно на удалёнке. Пишешь сотруднику из соседнего подразделения письмо, он не отвечает. Пишешь в мессенджере, не отвечает. Звонишь по служебному телефону, не отвечает. Психуешь, пишешь его начальнику, а начальник отвечает, что данный сотрудник уже неделю как уволился.
В крупных компаниях эйчар отдел, как правило, организует рассылку инфы о новых сотрудниках с фотографиями, должностями, заметками о хобби и интересах. А вот рассылку об уволившихся, как правило, не делают, чтобы не дизморалить коллектив, что приводит к ситуациям из первого абзаца.
Мне кажется, такую рассылку надо делать, информируя о том, что человек уходит, в день написания им заявления. Ну и писать, кому он передаёт дела.
* * *
О крикунах
А вот ещё как бывает. Вы начинаете внедрение некого нововведения, которое сильно поменяет ваши процессы и один из сотрудников начинает прям яро возражать. Не конструктивно, с предложениями, а эмоционально. Нет, это полная херня, мы так никогда не делали и делать не будем.
Инициируйте против этого сотрудника служебную проверку. 99,99 %, что найдёте ворох косяков, а может быть и распильно-откатную схему. В результате он либо будет уволен, либо успокоится и начнёт сотрудничать.
* * *
Сбрасывающийся параметр
Можно, конечно, сделать элемент интерфейса так, чтобы было удобно пользователю, но иногда это невыгодно бизнесу. Если сделать так, как удобно бизнесу, будет сильный негатив от пользователей.
Так родился один из самых мерзких дарк паттернов в дизайне — опция, которая через некоторое время сбрасывается в исходное состояние. Пример — переключатель умной ленты в линкадине. Можно отобразить «последние» новости, но она через пару дней опять возвращается в состояние «популярные», в котором месяцами наверху висят одни и те же пять постов.
* * *
Концепция играющего тренера не работает
Давным-давно, в одной софтверной компании у меня вышло глобальное непонимание с IT-директором. Он хотел, чтобы я, будучи руководителем продукта, самостоятельно собирал и писал требования хотя бы к части доработок и их потом «продюссировал».
Мне же казалось, что этим должен заниматься штат аналитиков, а мои дела всё же должны лежать в плоскости выстраиваний процессов, ведении переговоров с заказчиками и развитию отношений с ними, кадровой работе и решении периодически возникающих командных проблем и личных проблем сотрудников.
Я проработал в этой компании достаточно долго и сумел склонить чашу обязанностей в свою сторону, постепенно отойдя от исполнения работы рядового бизнес-аналитика в сторону более полезных для продукта вещей, но навсегда потеряв расположение руководителя, оставшегося при своём мнении, что руководитель продукта — в первую очередь эксперт по продукту, а бардак в процессах, как у других руководителей — это часть профессии.
Так вот, сегодня вычитал в одной бизнес-книге, что для того, чтобы стать руководителем системы, обязательно нужно перестать быть её частью. Схема «играющего тренера» не работает. Нельзя быть руководителем на 99 %, есть принципиальная разница между управленческим и исполнительным трудом и исполнять их эффективно одновременно невозможно.
* * *
О насыпании задач
Нужно быть осторожным с насыпанием задач линейным сотрудникам. Да, если вы топ или гендир, вполне можете наваливать замам с указанием приоритетов, это норм. А вот если вы линейный руководитель, на которого работают рядовые сотрудники, тут есть нюансы.
В идеале, конечно, выдавать подчинённым по одной задаче. Справился человек с задачей — он молодец, не справился — не молодец. Если выдать десять задач, он начнёт изобретать планирование и обязательно что-нибудь упустит. И тут вы можете совершить ошибку. Дело в том, что даже если сотрудник сделал девять из десяти задач, его нужно хвалить и выражать надежду, что в будущем он сможет в отведённые сроки решать все десять.
С мной однажды был случай. Работал я на одну софтверную компанию линейным бизнес-аналитиком и задачи прям сыпались. В частности, в один прекрасный день я показал концепт новой крупной доработки айос-приложения разработчикам и они мне дали большое количество правок, штук тридцать. Дело было во второй половине дня, до этого совещания была ещё куча активностей, в общем, я притомился и внёс в ТЗ, условно 28 правок, две штуки оставив на завтра.
На следующий день шеф сказал, что я не молодец и он штрафует меня на 500 рублей (дело было примерно в 2012 году и платили мне в районе 25000 руб и штраф был осязаем). Я сказал, что штраф несправедлив, он ответил, что не согласен и всё равно, штрафует. В итоге я отправил резюме в другую компанию и через неделю уволился, оставив работодателя без бизнес-аналитика, делавшего изрядную часть работы. Это, конечно, достаточно экстремальное решение, многие сотрудники такие штрафы спокойно терпели, но я всё равно, настоятельно рекомендую, если сотрудник сделал 8-9 задач из 10, всё равно, его хвалить, тогда мотивация у него будет на уровне.
* * *
О типах задач
Сначала нас 10-11 лет в школе, а потом 5-6 лет в институте учат решать разнообразные задачи, в которых нужно с исходными данными проводить разные манипуляции, а потом мы попадаем в реальный мир, в котором, оказывается, эти манипуляции делаются на компе одним движением, а главная задача состоит в том, чтобы корректно собрать исходные данные.
Иными словами, нет ничего ценного в том, чтобы уметь складывать 2 и 2, нужно уметь определить, что складывать нужно именно их.
