Многие руководители жалуются на «испорченный телефон» при передаче важной инфы подчинённым. Даже когда они собирают большое совещание на кучу народа, выступают на этом совещании лично, рассказывают подробно, приводят доводы, почему-то изрядная часть сотрудников их не слышит.
Часто ошибка заключается в том, что вы высоко сидите, далеко глядите, а подчинённые погрязли в операционке и им просто не до ваших стратегических распоряжений, предостережений, увещеваний, справиться бы с текущими вопросами. В такой ситуации лучше вообще отказаться от такого информирования и помочь разгрести операционку.
Если же эта проблема неактуальна, то применяем следующие решения:
Привлеките внимание
Объясните коллегам, почему ваше сообщение важно. Можно использовать какую-нибудь яркую метафору. В мою бытность продактом «Системных технологий», гендиректор однажды на собрании провёл параллель с детьми Могадишо. Ну, что типа на словах всех волнует судьба детей в Могадишо, но, положа руку на сердце, нам на них плевать. И было бы неплохо, чтобы мы перестали относиться к нашим продуктам как к детям в Могадишо. Из памяти стёрлось, о чём была остальная часть собрания, но параллель запомнилась. Ну и пункт был выполнен, внимание было привлечено. Можно рассказать о конкретных угрозах, какой-то опасной ситуации, которая может произойти и которая напрямую повлияет на людей в зале.
Дайте решение
Да, бывают совещания, которые как раз посвящены выработке решения, всякие мозговые штурмы, мозговые атаки и проч. Но мы говорим о немного другой ситуации, когда всё более-менее определённо и вы знаете, что делать. Поясните в общих чертах основные пункты плана, по которому будем действовать, чтобы угроза, озвученная в предыдущем пункте, не стала реальностью.
Распределите роли
Объясните, какой именно руководитель какого именно отдела какую часть плана будет выполнять. Если необходимо, детализируйте до уровня ключевых исполнителей. Без этого хода, не вполне ясно, кто и что должен делать, люди могут понадеяться друг на друга и ваш план провалится.
Вам совершенно точно придётся несколько раз повторить сказанное в предыдущих пунктах. Обязательно нужно разослать по итогам информирования письмо, в котором информация будет продублирована. Не исключено, что распределение ролей придётся повторить устно. Это нормально, мало кто с ходу воспринимает и запоминает новую информацию, особенно в условиях информационного шума. Это никому не нравится, но если вы действительно хотите донести важную информацию, придётся это делать.
Ответьте на вопросы
Вы не обязаны знать все аспекты работы всех подчинённых во всех деталях. Поэтому, когда они начнут осознавать сказанное и мапить на свою работу, неизбежно вылезут вопросы и шероховатости. И наличие этих вопросов — хороший знак. Крайне важно поощрить вопросы и грамотно на них ответить. Возможно, вы что-то не учли и кому-то понадобятся дополнительные ресурсы или методологическая поддержка.
Нужно ли выносить решения на командное голосование — спорный вопрос и предмет большого холивара. Многие методологи считают, что менеджер должен все решения принимать самостоятельно. Хотите что-то внедрить — внедряйте. Но предположим, вы придерживаетесь другого мнения, либо у вас действительно есть вопросы, которые лучше выставить на командное голосование.
Проблема в том, что обычно голосуют с бинарными вариантами ответов — либо за, либо против. Такой вариант не учитывает, что есть колеблющиеся люди. Можно для них ввести вариант ответа «воздержался», но я хочу рассказать о способе, который лучше и нагляднее.
Вы озвучиваете предмет голосования, участники задают вопросы, после чего приступают к голосованию. Участники демонстрируют своё мнение, показывая руку, от кулака до пяти открытых пальцев на камеру или отправляя соответствующий эмодзи в чат, если вы без камер. В частности:
👊 Закрытый кулак означает сильное несогласие или полное «нет».
👆 Один палец указывает на огромные сомнения по поводу предложенного решения.
✌️ Два пальца означают, что по решению есть сомнения, которые необходимо обсудить, прежде чем принять решение.
🤟 Три пальца свидетельствуют о том, что вы не против попробовать, но есть пара моментов, которые нужно учесть после принятия решения.
🤘🤘 Четыре пальца означают согласие, но с некоторыми мелкими сомнениями.
🖐️ Пять пальцев демонстрируют полное согласие, энтузиазм по поводу решения, отчётливое «да».
Если мнения, преимущественно от трёх до пяти, решение можно считать принятым. Если много троек — обсуждаем сомнения. Если преобладают двойки, единицы и кулаки, решение отклоняется.
Методика позволяет быстро понять отношение группы к вопросу, без необходимости тратить время, давая традиционно высказаться каждому члену команды. Она стимулирует участие каждого члена команды, повышая вовлечённость в принятие решений. Она провоцирует диалог по обсуждаемому вопросу.
Я всё же противник голосований, но если голосовать — то методом Fist to Five.
Категорически не люблю возводить в кумиры ныне живущих людей, ведь любой из них в любой момент может отмочить что-нибудь мерзкое. Но прочитав книгу Сатьи Наделлы «Обновить страницу», я обнаружил большое родство взглядов с этим выдающимся топ-менеджером и посчитал его ролевую модель достойной.
Больше всего меня впечатлила инфа о том, что именно Сатья Наделла прекратил войну с опенсорсом и начал дружить с компаниями, всегда считавшимися заклятыми врагами Майкрософта.
В Майкрософт всегда говорили, что Linux – раковая опухоль и опенсорс чрезвычайно вреден. Сейчас в никсовых системах прекрасно поддерживается Azure, а на гитхаб выложен исходный код множества мелкомягких продуктов.
На ежегодной маркетинговой конференции Salesforce Сатья Наделла демонстративно вынул из кармана айфон. Когда аханья и оханья о том, что это неслыханно, стихли, он продемонстрировал экран, на котором были все ключевые майкрософтовские приложения. И на Андроид вы можете скачать и ворд, и эксель. Более того, на планшетах Amazon доступен поиск Bing. И всё это взаимовыгодно.
Вот истинный корпоративный дзен. Не слепая конкуренция, а согласованные действия, выгодные всем сторонам.
* * *
Об осмысленности
Александр Васильевич Суворов придерживался мнения, что абсолютно все его подчинённые должны знать стратегию и тактику предстоящего сражения, от генерала до солдата. Это накладывает определённые риски — если кого-то из них возьмут в плен, смогут выпытать детали плана. Однако плюсы, выражающиеся в осмысленных действиях военных на поле брани, сильно перевешивают. Суворов провёл около 60 сражений и ни одного не проиграл.
В бизнесе этот принцип тоже действует. Когда понимаешь стратегию и цели своей компании и когда действия руководства прозрачны, работается сильно веселее.
* * *
Об оптимизации Избранного в Телеграм
Если вы часто сохраняете в Избранное тележеньки всякие посты, оно быстро захламляется и найти в нём что-либо становится трудно. Заведите несколько приватных каналов по тематикам сохранёнок и кидайте посты туда, искать будет сильно легче.
* * *
О том, как ставить вопрос на собесе
Инсайты для рекрутеров. Предположим, вашему нанимателю нужно сделать интернет-магазин и под это требуется пиэм.
Если данный пиэм не делал интернет-магазины, но делал другие продукты, совершенно не факт, что он не справится.
Если данный пиэм делал интернет-магазины, совершенно не факт, что он справится.
Косвенное следствие. Совершенно бессмысленно спрашивать: «Расскажите, как вы делали x?» Надо спрашивать: «Как по-вашему, правильно делать x?»
* * *
О портфельном подходе
Если компания сосредоточивается на коротких проектах, которые принесут прибыль здесь и сейчас, она теряет стратегические преимущества. Если делает только стратегические проекты, повышается риск кассовых разрывов.
Разумно применять портфельный подход. То есть, треть проектов, которые можно будет зарелизить в перспективе нескольких месяцев, треть среднесрочных проектов, треть долгосрочных. Так победим.
* * *
О теории и практике
В пиэмском чатике один коллега написал, что его на собеседовании на сениор прожекта мучили теорией, определениями и всякими формулами. Мысль такая, что эти знания больше для джуна, а сениор всё же больше про практику и помнить их не обязан.
Мне же кажется, что сениор пиэм уже должен в большей степени заниматься руководящей работой, менторингом, регламентами, методологией, нежели непосредственно ведением проектов, которым, на мой взгляд, должен заниматься мидл.
Параллель с реальным миром — электрику, действительно, не нужно помнить закон Ома, ему важнее знать, куда можно лезть руками, а куда не стоит. Но профессору электротехники закон Ома, равно как и всю остальную базовую физику, знать необходимо.
Придумал термин «инфофриган». Это человек, который бесплатно потребляет слитые инфокурсы.
* * *
О мышках и ёжиках
Важная мысль. Можно быть либо мышкой, либо ёжиком, среднего варианта нет. Ваша компания либо целиком работает по-белому — платит налоги, проходит проверки без взяток, платит официальную зарплату и требует от сотрудников кристальной честности, либо наоборот. Быть «серым», соблюдая закон частично, не получится, всё время будет что-то вылезать.
Быть «белым» ёжиком довольно прикольно. Читал случай, как в такую компанию (автодилер) приехали три тётки из Роспотребнадзора с проверкой. Ну и стали намекать — было бы неплохо пообедать, было бы неплохо нас развезти после работы домой и всё такое. Ну и по окончании проверки гендир распорядился главбуху, чтобы тот написал в Роспотребнадзор официальное письмо, что его сотрудницы съели обедов и прокатали за три дня проверки на 12 тыс. руб., ну и счёт. Видеть их лица было особенным удовольствием. Проверку прошли.
Или пожарные. Приехали, прогулялись по офису, сказали официально, что недоработки такие-то, в общей сложности исправлять миллиона на полтора, а неофициально добавили, что можно им положить в книжечку триста тысяч на всех и они всё подпишут. А гендир говорит, ничего подобного, будем исправлять. Но как так, это же невыгодно. А мы ёжики. Исправили, прошли проверку официально.
В ёжиковой компании сотрудники знают, что с ними обращаются честно, отражают в ведомостях всю зарплату, платят отчисления в пенсионный и ОМС, оплачивают больничный, но в то же время точно знают, что в случае реализации ими серой схемы, эту схему вычислят и их уволят с позором. И это очень ценно.
Быть ёжиком прикольно.
* * *
О кабинетах руководителей
Кабинеты руководителей, по крайней мере, в бизнесе, вышли из моды, оставшись прерогативой госов. В коммерческой компании руководитель обычно сидит вместе со всеми. И это, на мой взгляд, плохо, потому что основным предназначением отдельного кабинета было запираться в нём и плакать. Потому что демонстрировать публично своё отчаянье и понимание, что проект проваливается, категорически нельзя.
Однако с приходом удалёнки, у руководителей появилась возможность становиться на полчаса оффлайн и плакать в собственной ванной, свернувшись на полу в позе эмбриона.
* * *
О табличках
Обнаружил канал человека, увлекающегося коллекционированием советских и царских табличек. Подумал, что из современного мира информационные таблички как-то ушли. Сейчас можно встретить табличку на кабинете врача (чаще всего, без фамилии) или большого чиновника в мэрии или университете.
А вот вместо информационных табличек сейчас всё больше распечатанные на листочке A4 послания (иногда в полиэтиленовых файликах). Потихоньку утратилась и технология производства долговременных табличек. Думаю, это всё из-за ускорения темпов жизни, в условиях которых эмалевой табличке просто нет места.
Пришёл к выводу, что на собеседовании надо на один какой-нибудь вопрос обязательно сказать, что вы не знаете ответа. Терминаторов, отвечающих на любой вопрос, как это делается по методологии, как делал он и как правильно, почему-то не любят и под разными причинами шлют отказы.
* * *
О вокабуляре
В QIP был крутой плагин, позволяющий изменить ваш вокабуляр. Он анализировал историю всех сообщений и выдавал статистику, сколько у вас всего слов и словоформ и сколько раз вы употребили каждое слово. В телеге, видимо, из-за особенностей хранения истории сообщений, это сделать не так просто.
У меня было около 120 тыс., но это с учётом всех словоформ, мата и сленга.
Есть бот @Slov0bot, но он считает только в чатах, в которые его добавили. Личку анализировать не умеет. Печаль.
* * *
О редиректах
А вот ещё как бывает. Вы переходите по прямой ссылке на некий сайт и хотите с ней сделать что-то полезное. Скачать материал, посмотреть ролик, неважно. И сайт говорит, что вы не можете сделать это без регистрации или авторизации. Вы авторизуетесь\регистрируетесь и оказываетесь в личном кабинете или на главной странице. Хорошо, если ссылка на требуемый материал где-то сохранилась, но чаще пользователь просто матерится и уходит с этого сайта навсегда.
Конечно же, если пользователь инициировал авторизацию\регистрацию с контентной страницы, его по завершении процесса, нужно редиректить обратно на эту страницу.
* * *
Об искусственном интеллекте
Ситуация с искусственным интеллектом напоминаем мне ситуацию с автопилотом. Да, сейчас автопилот выполняет большую часть работы по управлению самолётами, но это не сделало пилотов тотально безработными или менее высокооплачиваемыми. Просто их работа сильно изменилась.
* * *
О целостности
Если кандидат в менеджеры проектов пишет вам письмо, в котором в каждом третьем слове ошибка или опечатка, после трудоустройства он будет также делать ошибки в документации и письмах клиентам.
Если он опоздал на собеседование на десять минут, будет опаздывать и на рабочие встречи.
Если у него рабочий стол завален ярлыками, документами и чёрт-те чем, будет такой же завал в проектной документации.
Люди, как правило, целостны в своих недостатках.
* * *
Снова об онбординге
Ещё немного об онбординге. Допустим, вы проводите вводную беседу с новичком. Ну и по ходу разговора кидаете в него в чате ссылками. Вот пространство в конфлю, вот проект в джире, вот страница команды, вот роадмап, вот… Большинство онбордящих не снабжает эти ссылки комментариями, чтобы уменьшить время кидания. Не делайте так, пожалуйста. Сделайте для каждой онбордимой должности документ, в котором сгруппируйте полезные ссылки, напишите заголовки и комментарий к каждой ссылке и кидайтесь этим документом в новичка в один приём. Этот подход сэкономит ваше время и время новичка.
Да, и ещё один момент. Доступы. Бегать по сисадминам и саппортёрам и выпрашивать доступы к документам, которыми вы в него кидаетесь, сотрудник не должен. Это должны сделать вы, не позднее, чем за день до выхода этого сотрудника на работу.
* * *
О вебмастерах
Профессия вебмастера, когда один человек и дизайнил, и реализовывал, да ещё и тексты придумывал, ушла в прошлое, вместе с Web 1.0 На хедхантере сейчас нет ни одной вакансии с таким названием.
Но реальность стала чудной настолько, что в условиях повсеместной экономии, эта профессия может воскреснуть.
* * *
О роботе-психотерапевте
Мне нравятся визуальные новеллы. Последней я прошёл «Eliza» 2019 года. Новелла про девушку, устраивающуюся «прокси» к роботу-психотерапевту. В будущем люди морально готовы, чтобы их консультировал робот, но непосредственно общаться пока предпочитают с живыми «прокси», которые зачитывают реплики машины.
Новелла не слишком технологичная и без особой драмы, так что, рекомендовать не стану. А пишу о ней, потому что вчера прочёл в книге «ChatGPT и Революция Искусственного Интеллекта» Тимура Казанцева о том, что робот-психотерапевт Eliza существовал в прошлом, хотя и был довольно примитивен. В наше время многие люди используют ChatGPT в качестве психотерапевта, он их неплохо поддерживает, хоть и рекомендует иногда чушь. То ли ещё будет.
* * *
Об интересе и таланте
Наблюдение. Если у вас есть искренний устойчивый интерес к чему-либо, скорее всего, у вас есть к этому склонность или талант. И наоборот, если нечто вас совершенно не интересует, скорее всего, склонности к этому нет.
Есть такая шутка о том, что женщины не понимают, как мужчины выходят из дома без запасного свитера, бутылки воды, таблеток, пудреницы, шоколадки, дезодоранта, салфеток, иголок с нитками, бальзама для губ, расчёски, а просто кладут потёртый бумажник в карман и идут.
Посмотрел несколько видео подборки «Что в сумке», там, в основном, разные известные женщины и Даня Милохин. И чего там только нет. У Эммы Уотсон, например, есть даже свинка с мячиком и пушистая грелка, об которую она греется в самолётах. И ни у кого ни разу не встретил самого обычного простенького ножика. Я не говорю о страшных выкидухах с упорами, обычный няшный викторинокс. И вот как они обходятся без этого предмета, мне вообще неясно.
* * *
О поиске по архивам
Яндекс запустил поиск по архивам. Полезно для интересующихся генеалогией. Архивов доступно пока не очень много, но сервис сносно ищет по древним рукописным документам.
* * *
О фамилиях
Система каталога сотрудников компании, в которой хранятся имейлы, аккаунты в мессенджерах и другие контактные данные коллег, обязательно должна учитывать, что девушки имеют свойство выходить замуж и менять фамилии. Система должна уметь хранить массив фамилий и искать по всем.
Самое начало Вигерса
* * *
О невмешательстве государства и другом мире
Я понял, что мне кажется непривычным в фильмах и книгах о Джобсе и Айве. В них вообще не фигурируют госчиновники. Не то, что ни одного министра, даже ни одного главы комитета не упоминается вообще.
Бизнесмен Стив Джобс договорился с другим бизнесменом, Майком Марккулой, получил деньги, сделал бизнес. Потом договаривался с другими инвесторами, получал деньги от них. И никакого участия государства, никакого. Я не слышал, чтобы Белый Дом заказал ему десять тысяч айфонов или Пентагон — айпадов.
Всё-таки, другой мир эта Америка.
* * *
О драме
Пытался нагуглить определение драмы, нагуглил много мути, но так и не нашёл внятного, неразмытого определения. Пишут про обязательное единство времени, места и действия, но не пишут главное. А главное в том, что драма — это когда все стороны конфликта одновременно правы.
Все же досмотрели первый сезон Last of us? Если не досмотрели, не читайте дальше.
Драма из Last of us
Тётка, которая хочет сделать девочке операцию, права. Убить одного ребёнка, но создать вакцину от зомбификации, великая цель. Но и Педро Паскаль тоже прав, он привязался к девочке, не хочет, чтобы она умирала и считает, что жертвовать никем нельзя, это недопустимо. Отличный пример драмы.
Если вы, как и 3,95 млрд человек, пользуетесь смартфоном, не можете не столкнуться с пушами. Сообщение, иногда с картинкой, прилетает в шторку уведомлений и отвлекает на себя внимание. Самая большая засада, когда у приложения нет опций, какие именно пуши слать, а какие не надо и вы не можете отписаться от них полностью, чтобы не пропускать важные уведомления. Простыми словами — вы хотите получать от банка пуши о транзакциях, но не хотите рекламу, но отключить можно только сразу всё. Приходится мириться. Пожалуйста, разрешайте в своих приложениях отключать рекламные пуши. А пока давайте разберёмся, что это такое и как работает с точки зрения пиэма.
Изначально эта технология не имела отношения к мобильным устройствам и использовалась для рассылки уведомлений о судебных событиях подписчикам этих событий. Ещё с её помощью слали новости фондового рынка биржевым торговцам. Чуть позже, во время войны браузеров, Майкрософт и Нетскейп внедрили пуши в свои браузеры, но по ряду причин тогда взлетела технология RSS. Ещё чуть позже её внедрили Гугл и Эппл в свои мобильные операционки и вот тогда она уже заработала нормально.
Дальше немного технических деталей.
APNS
На устройствах Apple для работы с пушами используется сервис APNS. Через него пуши отправляются как на iOS, так и на OS X (через Центр уведомлений) и OS X Server (отправка почты, календаря и контактов на устройства пользователей сети).
Схема работы APNS, картинка с Хабра.
Важный момент — для получения сообщения APNS, приложение-адресат необязательно должно быть запущено, пуш придёт в любом случае.
GCM
А на Android-устройства пуши отправляются при помощи гуглового сервиса GCM. Кроме того, через GCM пуши могут отправляться в приложения и расширения для Chrome.
Схема работы GCM, картинка с mavink.com
Важный момент — одно устройство с одним идентификатором регистрации может получать уведомления сразу с нескольких серверов. Уведомления живут долго, до 4 недель. GCM будет хранить их, пока не доставит или не истечёт этот срок.
Пуши с точки зрения юзабилити
Форма подписки. Пожалуйста, не требуйте от пользователя подписку на пуши сразу после установки и первого открытия приложения, конверсия будет низкой, так как значимость пушей именно от вас ещё предстоит доказать. Лучше сделайте возможность подписки на пуши в виде опции в настройках, а предлагайте, когда пользователь задействует внутреннюю подписку на что-нибудь.
Форма уведомления. У сервисов пушей есть ограничения по размеру сообщения (2 килобайта для APNS и 4 килобайта для GCM) и по времени, которое пользователь готов потратить на его прочтение. Размещайте в тексте пуша значимое сообщение, например, как Яндекс Еде: «В честь вашего дня рождения, дарим промокод EDA24 на бесплатную доставку заказа от 800 руб.»
Гибкая настройка. Я в начале статьи упомянул, что невозможность отключить рекламные пуши, сохранив информационные, очень раздражает. Дайте пользователю возможность гибко настроить, какие пуши он будет получать, это даст дополнительную лояльность.
Интерес пользователя. Используйте аналитику и привязку к координатам, чтобы сделать пуши ещё более специализированными. Например, появление нового ресторана вашей сети на другом конце Москвы пользователя вряд ли заинтересует, в отличие от появления такого же заведения в его районе. Пуш о новогодних скидках 2 января не заинтересует вообще никого. Используйте сегментирование, например промокод на первый заказ нет смысла слать давним пользователям. Собирайте также статистику пушей, какие пуши чаще открывали, в какое время и всё такое. Помните о часовых поясах.
Звук уведомлений. Настройте свой, неповторимый. Чтобы пользователь знал, что новое сообщение пришло именно от вашего приложения. Такой звук есть, например, у приложения ВТБ, его пуш не перепутаешь ни с каким другим. Это тоже может стать преимуществом.
Оптимальной работы push-уведомлений можно добиться, объединив их на единой платформе с другими каналами связи, такими как электронная почта, SMS и голосовые звонки. Комплексный подход к коммуникации с клиентом сделает этот процесс бесшовным и эффективным.
Метод появился в компании «Toyota» в 1959 году. К айти имеет косвенное отношение, почитать про него можете в Википедии.
Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.
В отличие от Скрама, Канбан не слишком строг. Скрам не может применяться частично, если вы используете не все практики, это уже не Скрам. В случае с Канбаном, нет правильного и неправильного Канбана, вы можете использовать те практики, которые вам лучше подходят.
Канбан может применяться не только в айти, но и везде, где есть регулярное производство с повторяемыми этапами, через которые должна проходить каждая задача.
Канбан-доска
Главный принцип Канбана — визуализация при помощи канбан-доски. Рассмотрим её подробно.
Левая колонка — очередь. По-хорошему, надо раз в пару недель проводить встречу по наполнению её задачами, но на практике обычно заинтересованные лица закидывают туда задачи по мере поступления. Можно установить ограничение на максимальный размер очереди.
Правее очереди следует расположить колонки допроизводственных этапов, на которых происходит сбор требований, оценка и утверждение задачи. Дальше идёт черта — точка принятия обязательств. Если задача пересекает эту черту, это означает, что она передана в производство и совершенно точно должна быть сделана и влита в продукт.
Перед последней колонкой вторая черта — точка отдачи обязательств, переход задачи через неё означает, что команда ручается, что с задачей всё в порядке.
Пример канбан-доски с scrumtrek.ru
Количество карточек в каждой колонке, кроме первой (это на ваше усмотрение) и последней, должно быть ограничено реальной максимальной пропускной способностью команды, она определяется экспериментально.
Канбан-доска — не только инструмент визуализации процесса, но и рефлексии. Внимательно рассмотрев доску, можно выявить производственные этапы, которые на самом деле не нужны, и наоборот недостающие этапы. По размеру очереди задач и накалу страстей на битве заказчиков за места в этой очереди, можно определить, насколько «жив» продукт.
Также при помощи этой доски вы можете выявить узкие места, «бутылочные горлышки», в которых скапливаются задачи и замедляют цикл производства.
WIP-лимиты
WIP (work in progress) — это количество элементов, находящихся в работе в настоящий момент. Его не надо путать с WIP-лимитом, ограничением на количество элементов в работе на настоящий момент времени, введённым для достижения некой цели.
Единой формулы для расчёта этого лимита не существует, он подбирается экспериментально. Одно можно сказать определённо — этот лимит вовсе не должен быть маленьким.
Использование WIP-лимита повышает определённость в работе. Потому что чем больше элементов в разных состояниях, тем тяжелее ими управлять и контролировать.
Для того, чтобы посмотреть максимальный WIP-лимит по команде, потребуется отчёт CFD (cumulative flow diagram) или накопительная диаграмма потока.
Пример накопительной диаграммы потока с darvindigital.ru
Каденции
Каденциями называются регулярные встречи при помощи которых вы можете поддерживать и улучшать канбан-процесс в команде.
Канбан-митинг
Пятнадцатиминутная ежедневная встреча. Команда собирается и обсуждает:
Что нам мешает?
Как осуществляется поток работы?
Что мы можем улучшить?
Очень важно обсудить все заторы и затруднения в работе над задачами. Возможно, кому-то из участников нужно оказать помощь.
Встреча по пополнению
Получасовая встреча, проводится раз в неделю. Обсуждаем с заинтересованными лицами, какие новые задачи имеет смысл взять в работу и как переприоритизировать существующие, у них могла поменяться актуальность. Если получаса не хватает, можно общаться и дольше.
Обзор сервиса поставки
Получасовая встреча, раз в две недели. В этой встрече должны участвовать ключевые заказчики, менеджер и представители команды разработки. Обсуждаем удовлетворённость заказчика, показываем метрики, думаем, как же нам улучшить работу команды.
Встреча по планированию поставки
Эта встреча нужна, если у вас есть выделенные релизы. В современных айти-проектах всё чаще используется непрерывная интеграция, когда фичи вливаются в продукт по мере готовности, но всё становится сложно, если у вас есть несколько соседних продуктов и нужно обеспечить синхронность релизов.
Если это так, имеет смысл перед поставкой провести планирование списка фич, которые должны войти в поставку и обсудить, что для этого нужно сделать. Обязательно нужно спланировать мероприятия по обучению пользователей работе с вливаемой функциональностью.
Обзор рисков
Часовая ежемесячная встреча. Имеет смысл собраться со всей командой и обсудить, какие риски появились на горизонте, какие могут сработать, а какие уже сработали и влияют на поставку.
Обзор операций
Это кросспродуктовая встреча, на которой обсуждается межкомандное взаимодействие. Собраться с менеджерами соседних продуктов и обсудить, что мешает делать кросспродуктовые доработки. Раз в месяц достаточно.
Обзор стратегии
Самая редкая встреча, её достаточно проводить раз в квартал. Собираемся с руководством компании, обсуждаем рынок, среду, глобальные вопросы. Ставим цели для команды на квартал. Выявляем стратегические проблемы, корректируем тактику команды.
Метрики в Канбане
Важнейшая метрика в Канбане называется Lead Time — время прохождения задачи от точки принятия обязательств до точки отдачи обязательств. Чем быстрее задача проходит от одной точки до другой, тем команда эффективнее. Кроме того, есть ещё такие метрики:
Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).
Делаем правила явными
Нужно проговорить с командой и зафиксировать в виде документа все канбан-правила, которые будут применяться в вашей команде. Особенно важно описать критерии, по которым карточка перемещается из одной колонки в другую и при каких условиях она может быть перенесена обратно.
Хорошо и правильно проговорить с заказчиками правила приоритизации задач. Надо также надо обсудить протоколы, по которым будет проводиться работа со более и менее срочными задачами. Когда людям понятны правила, они готовы и хотят играть работать самостоятельно.
Кейс внедрения канбана в реальной практике
Когда я только начинал практику руководителя разработки, столкнулся с проблемой. Есть внутренний заказчик в виде группы внедрения, есть исполнитель в виде SQL-отдела. От заказчика к исполнителю постоянно поступает поток запросов на SQL-доработки — всевозможные отчёты, скрипты, кастомные импорты. И существует постоянно высказываемая претензия — совершенно невозможно понять, когда та или иная доработка будет сдана.
Оказалось, что отдел использует TFS (сейчас Azure DevOps Server), однако совершенно бессистемно. Кто-нибудь из руководства заводит запрос на доработку, вешает его на рандомного разраба и заказчики ждут у моря погоды. Если какой-то запрос нужен срочно, ответственный внедренец прибегает к руководству департамента и начинает орать. CIO транслирует ор в программиста, он в приоритетном порядке запиливает доработку. Тестировать её некогда, поэтому она сразу накатывается на базу заказчика. Если возникают проблемы, они никак не регистрируются, внедренец просто приходит в отдел SQL, подсаживается к программисту и просит поправить.
Частично этот кейс был рассмотрен в статье «Единая точка входа», но там больше про унификацию входящих обращений, в этой же статье мы поговорим про визуализацию и контроль при помощи канбана.
В первую очередь было принято решение визуализировать очередь. Хотелось использовать веб-приложение, потому что внедренцы крайне не любят ставить сторонние приложения (лол) и вообще, большую часть времени проводят в аутлуке. Выбор пал на trello. Первоочередной задачей стало завести на трелло-доске все открытые запросы на доработку из TFS. Trello тогда умел создавать карточки на основании писем, отправленных на специальную почту, а TFS умел экспортировать воркайтемы в эксель. Мой разраб минут за сорок накидал VBA-скрипт, импортировали запросы.
А вот дальше мы пошли вразрез с классическим канбаном. Вместо столбцов, отражающих этапы работы, мы завели по столбцу на каждого разраба и добавили в эти столбцы карточки запросов, над которыми они работали в данный момент.
Ситуация улучшилась, вместо: «Я не знаю, когда мы сделаем эту задачу», появилась возможность говорить: «Перед этой задачей в очереди ещё шесть задач, сможем взять её в работу после них». Удалось достигнуть договорённости — мы объявляем срок по задаче только после того, как она поступает в работу разрабу, но за этот срок уже отвечаем по полной программе.
Мы стали встречаться со старшим внедренцем два раза в неделю и обсуждать сроки по задачам, взятым в работу, а также положение разных задач в очереди. Так как 80 % задач были от одного и того же заказчика, мы разрешили внедренцу менять очерёдность задач этого заказчика. Если было нужно подвинуть задачи другого заказчика, внедренцы договаривались между собой.
Порядка стало больше, но возникла проблема с приёмкой задач. Так как внедренцы не торопились принимать задачи, их карточки намертво повисали в колонках разрабов, стали копиться внушительные хвосты. Так как решить проблему на организационном уровне не удалось, мы сменили инструмент.
kanbanize.com, в отличие от trello на тот момент поддерживал свимлайны. То есть, можно было завести для каждого разраба дорожку, а колонками сделать уже актуальные статусы, что сильно ближе к нормальному канбану. Кроме того, этот сервис позволял добавить кастомные поля к каждой карточке, что было для нас очень важно, так как кроме TFS-идентифкатора, каждый запрос имел CRM-идентификатор, которыми оперировали внедренцы.
В целом, сочетание организационных мер с правильно подобранным инструментом и методологией, позволили преодолеть кризис и сделать разработку предсказуемой. Негатив от внедренцев закончился.
Изображение с сайта unsplash.com, автор Tom Hermans
О необъятности книг
В мире огромное количество книг. В квартире, в которой я провёл детство, был большой шкаф с книгами. А в школьной библиотеке десяток длиннющих стеллажей с книгами. В городской ещё больше. А в какой-нибудь Ленинке, по сравнению с этим, просто море книг.
Сегодня видел фотографии книжных полок какой-то стокгольмской библиотеки (пик). То есть, ведь в каждой стране есть огромное количество книг на национальном языке. Это тяжело даже в принципе, осмыслить.
Стокгольмская общественная библиотека
Яндекс говорит, что в мире в данный момент 129 864 880 книг. Я предпочитаю слушать, а не читать, и комфортно слушаю 2 книги в месяц. Значит, чтобы их прослушать, мне нужно 5 411 036,6 лет. По сравнению с возрастом Земли (4,54 миллиарда лет) не очень долго, но дело в том, что пока я буду слушать 24 книги в год, в мире за этот год будет выходить ещё 1 млн. новых книг.
К счастью, большая часть этих книг — чудовищная графомания, вроде творений Инстасамки, Симоньян, Бузовой или, извините, Алекса Лесли. Значит, нужно либо научиться определять 1 % значимых книг, либо изобрести революционно новую технологию по загрузке их в мозг.
Такие дела.
* * *
Кто о чём, а я про ё.
Афера. Слово из фр. affaire – дело. Произносится через букву Е. Никаких Ё тут нет.
Платёжеспособный. А вот здесь Ё нужна. Вся суть в том, что в слове есть основное ударение и побочное, которое как раз падает на букву Ё.
Истекший – истёкший. А в этом случае нужно смотреть на смысл. Если мы говорим о жидкости (истёкший кровью), то нужна буква Ё. Если же про время (истекший год), то нужна буква Е.
А ещё, букву ё обязательно нужно писать в новых словах. Например, вы знаете, что тверк на самом деле твёрк, а ЧВК Редан на самом деле Рёдан? История сама примет решение о значимости этих явлений, но пока эти слова новые, ё лучше не игнорить.
* * *
О финансовой дисциплине
Финансовая дисциплина и домашняя бухгалтерия не сделают вас новыми Безосами сами по себе, но они помогут оптимизировать затраты, сформировать запас денег на тяжёлые времена, а также выделить суммы, которые можно безопасно инвестировать.
Но мешает мышление. Когда-то давно я курил, но не покупал пачку каждый день в магазине, а раз в два с половиной-три месяца приезжал в оптовый магазин и брал сразу 10 блоков. И один мой друг никак не мог этого понять. Я объясняю, во-первых, оптом процентов на десять дешевле. Во-вторых, у тебя нет проблемы закончившихся в ночи сигарет. Ты просто достаёшь пачки из блоков, заначенных в шкафу и куришь. Сигареты не портятся, держать в холодильнике их не нужно. Чистая экономия и оптимизация.
А он говорит, как же так, единовременно отдать за сигареты 6-8 тысяч, да, после этого не будет проблем с сигаретами, зато появятся проблемы с деньгами.
Учёт доходов и расходов помогает сломать это мышление и начать оптимизировать затраты. Но в итоге это закончилось это тем, что мы оба бросили курить. Я вообще (3 года, 8 месяцев и 22 дня ни одной сигареты), он перешёл на кальян, что тоже несколько дешевле.
* * *
О старинном кеке
Слово «кекнуть» тогда означало «икнуть». Ничто не ново.
Нашёл картинку и загрустил. В 2009 году я уже закончил универ и год как страдал фигнёй в роли фотографа агентства развлечений, взаимодействие с которым закончилось с кризисом конца 2008, когда гражданам стало не то, что не до развлечений, но на фотографе стали экономить.
Благодаря успешно сделанному тестовому, получил работу в геймдев-компании «Айгринд», снял квартиру в конце проспекта Мира, купил небольшой нетбук и радовался жизни. Нашёл подработку юзабилити-аудитором, где зарабатывал на излишества. А почему бы не заработать? Доллар чуть дороже 30 рублей, ни с кем не воюем, слово «санкции» ещё даже не звучало в публичном поле. Хороший ужин в ресторане, алкоголь без ограничений и счёт редко превышает 1000 рублей.
Калининградский продавец стиральных машин Алексей Беба бросает продажи и создаёт театральную студию «Эволюция», я начинаю туда ходить и учусь у отличных актёров Елены Мочаловой и Антона Арнтгольца. Занятия проходят в банкетном зале ресторана «Ольштын» поздно вечером, часто не удаётся попасть на автобус или маршрутку до съёмной квартиры, Яндекс Такси ещё не придумали. Через раз совершаю длинную прогулку через весь Калининград. Зима, но не грязно.
Уже год как существует Роскомнадзор, но до первых блокировок ещё долгие пять лет. Вконтакте заменяет малофункциональную стену на микроблог, становясь блог-платформой, хоть и довольно бестолковой — как искать интересных блогеров, было непонятно.
Выходит «Сталкер. Зов Припяти». До биткоин-истерии ещё долго, видеокарты стоят вполне вменяемых денег. Выходит отличный кооп «Left for dead 2», в который мы с друзьями играем до сих пор.
Потом будут сокращения в «Айгринде», отказ от предложения «Системных технологий» стать их продаваном, возвращение в родной город, неожиданное знакомство с Дуровым, подкидывание ему идей для ещё не загнившего «Вконтакте», долгий поиск нормальной работы, но всё это позже.
Мы никогда больше не будем так счастливы, как в 2009. Спасибо за воспоминания, рандомная картинка из интернета.
* * *
О трёх числах
В самом начале карьеры (примерно весна 2009 года) меня пригласили на собеседование на сисадмина в одну строительную компанию. И на собеседовании гендир сказал: «Назови, пожалуйста, три числа. Минимальную зарплату, за которую ты готов согласиться работать. Комфортную зарплату. И зарплату, с которой ты сможешь позволить себе излишества». Я, совершенно не понимая подвоха, назвал 15 тыс., 25 тыс. и 40 тыс.
Через несколько дней мне позвонили и сказали, что приглашают на испытательный. Я стал ездить к ним в офис, познакомился с предыдущим сисадмином (он продолжал оказывать этой компании услуги как ИП), стал настраивать всякое, помогать пользователям. Ну и дня через три решил спросить у гендира (договора мы не заключали), а какая у меня зарплата? А он и ответил: «15 тыс., ты же сам назвал эту сумму».
С тех пор я перестал отвечать на вопрос про три числа честно.
* * *
О любимых приложениях
У каждой профессии своё «любимое» приложение. В кавычках потому, что любимое оно не по причине нежных чувств, а от частого использования. Если вы большую часть времени видите на экранах людей эксель, значит это финансисты или бухгалтера. Если ворд — техписы или юристы. Редакторы презентаций жалует начальство. На экранах программистов разнообразнейшие IDE. UX/UI сидят в Figma.
А вот на экране пиэма чаще всего вы можете наблюдать мессенджер или почтовый клиент.
* * *
О подрыве и совершенствовании командного духа
Вашему вниманию три очень важные таблички из книги «Ещё более эффективный Agile», посвящённые способам подрыва и совершенствования разных аспектов работы команды.
* * *
О договорённостях в скраме
При классическом скраме команда обменивает гарантию выполнения целей спринта в обмен на невмешательство в скоуп спринта в процессе. Короткие итерации (2-3 недели) делают этот обмен вполне реальным.
То есть, команда реализует всё, что напланировано, но руководство в лице продакта и стейкхолдеров не вкидывают новых задач в спринт и не меняют постановку взятых задач.
Если ваше руководство не может сохранять фокус 2-3 недели и это происходит регулярно, у компании проблема.
* * *
О декриминализации ошибок и эскалаций
Есть разница между вредительством, когда сотрудник намеренно причиняет компании вред (например, хамит клиенту или сливает информацию конкурентам) и ошибкой, когда попытка достигнуть хорошей цели плохо заканчивается. Как менеджер, вы должны декриминализировать ошибки. Ошибки нужно разбирать, вытаскивать из них выученные уроки, возможно, писать публикации о них, но наказывать не надо.
А ещё, надо декриминализировать эскалации. Нет ничего хуже, чем ситуация, когда подчинённый боится сообщить вам о проблеме и тянет до последнего, пока это проблема не станет реально серьёзной и приведёт к финансовым потерям. Да, вы должны сопротивляться попыткам переложить на вас принятие решений по каждой мелочи, обязательно задавать вопрос: «А сам-то как считаешь?», но создавать систему, в которой сотрудники боятся эскалировать — менеджерское преступление.
* * *
Об эйджизме
Мне кажется, проблема эйджизма в перспективе десяти лет сильно уменьшится. У предыдущего поколения мышление существенно отличалось от миллениальского отсутствием понимания ценности цифрового имущества.
Я помню, как в детстве говорил отцу: «Папа, я набрал в Флинстоунах стопицот очков! Папа, я обыграл компьютер на чемпионате мира по футболу! Папа, я построил самый прибыльный парк развлечений!» И он всегда мне на это отвечал: «Ну и где в реальности твои стопицот очков, кубок мира и парк развлечений? Нет у тебя ничего.»
А виртуальные вещи так же ценны как и реальные. Броня T1 из Варкрафта так же полезна как кожаная куртка с меховой оторочкой в реальности. Аккаунт в Линкадине с SSI 75 или инстаграм с миллионом подписчиков так же ценен как крутые записи в трудовой книжке.
Но мои рассуждения о понимании миллениалами ценностей виртуальных предметов, которое делает их полезными в виртуализированном мире 2023 года, могут разбиться об ещё не изобретённую штуковину, которая отправит на помойку и наше мышление тоже.
* * *
Об источнике для нейросетевой копии
Потихоньку материализуется эпизод Чёрного Зеркала «Сейчас вернусь» (2 сезон, эпизод 1), в котором девушка при помощи нейросетей возвращает погибшего мужа, сначала в виде переписки, потом в виде голоса, а потом и в виде болванчика.
Дело в том, что тут один чувак возродил Стива Джобса. С ним теперь можно поговорить в мессенджере Фейсбука, нейронка с голосом, тембром и интонациями Джобса поддерживает беседу на любую тему.
Только вот вас можно будет возродить, исключительно если вы достаточно самодокументированы. Нейросети нужны материалы для обучения — фотки, посты, комментарии, лайки, переписки. Если ваша активность в соцсетях ограничивается одной фоткой за рулём, а в переписках вы только договариваетесь о попойках, цифровую личность будет лепить не с чего. Но может, оно и к лучшему.
* * *
Об увольнениях
Есть мнение, что если у вас возникла мысль, что сотрудника нужно уволить, его необходимо уволить немедленно. Я не являюсь сторонником этой идеи. Мне кажется, что если такая мысль возникла, над практикой этого сотрудника нужно установить наблюдение и начать фиксировать, какие именно ошибки он совершает и что хорошего при этом делает.
Если по итогам месяца такого аудита выясняется, что оценка косяков сотрудника в деньгах превышает оценку его пользы более чем в два раза, имеет смысл этот список сотруднику предъявить, аргументированно пояснив, почему вы его практикой недовольны и дать время исправиться. Если исправиться не получится, сотрудник воспримет новость об увольнении спокойно и скорее всего, без проблем напишет по собственному.
И ещё важный момент. Надо обязательно, хоть и без лишних подробностей, пояснить команде, почему Васю попросили написать заявление. Предъявлять им список васиных косяков не надо, достаточно передать суть. Например: «Васины задачи возвращались на доработку тестировщиками запредельно много (десятки) раз». Это предупредит ненужные разговоры и слухи.
* * *
О скорости онбординга и музыке
Дело в том, что я учился в музыкальной школе, в отделении народных инструментов, на баяниста. Ну и время от времени разучивал там новые песенки. Баянисты обычно сначала учатся играть партию правой руки, то есть, основную мелодию, потом левой руки, то есть, басы, потом соединяют двумя руками и учат наизусть, чтобы играть без нот.
Нормой считалось на первом занятии играть правую руку, на втором левую, на третьем обеими руками и приступать к выучиванию. Говорят, существуют музыкально одарённые дети, которые могут на первом занятии с листа играть двумя руками, но у нас таких не было. Так вот, к сути. Мне не хватало трёх занятий. Трудно давалось соединение, игра двумя руками, на это вечно уходило два-три дополнительных занятия.
Так, и что, вы скажете, что из-за этой особенности я учился не пять лет, а дольше? Ничего подобного, закончил музыкалку за пять пять лет, сыграл на выпускном экзамене положенный набор из шести произведений разных жанров, получил отличную оценку и диплом о начальном музыкальном образовании.
К сути. Некоторые новички могут проходить онбординг в вашей компании дольше других. Дольше разбираться в регламентах, хитросплетениях отношений отделов, не с первого раза правильно делать регулярные отчёты, тупить с джирой (её каждая компания настраивает под себя и какие-то время надо привыкать). Это не означает, что эти новички хуже других или что будут хуже вести реальные проекты или что их онбординг в целом, займёт больше времени. Разберутся за положенные три месяца и нервничать по этому поводу не надо. Это такая особенность мышления, которая не является ни положительной, ни отрицательной чертой.
Людей вообще, нельзя сравнивать друг с другом, это некорректно.
* * *
О простых доработках в клиентском сервисе
В клиентском сервисе есть вещи, которые вы можете встроить практически бесплатно и они при этом сильно поднимут лояльность клиентов, нужно только их найти.
Дело в том, что я заказываю рационы здоровой еды. Каждый вечер курьер привозит пакет с пятью блюдами в коробочках. Сменил три службы доставки и только в третьей догадались… класть коробочки в пакет в том порядке, в котором их нужно есть!
Казалось бы, что может быть проще и логичнее, класть наверх завтрак, затем перекус, затем обед, полдник и ужин. И тем не менее, у предыдущих двух доставок коробочки лежали в рандомном порядке.
* * *
О ватных палочках
Время для медицинского ликбеза. Ватными палочками лезть в уши нельзя категорически. В лучшем случае утрамбуете серу, в худшем поцарапаете проход или даже повредите барабанную перепонку. Вполне достаточно протирать наружную часть уха чистой водой или перекисью.
Палочки же предназначены для удаления макияжа. Ещё такую палочку можно окунуть в йод и обработать края раны, но на этом всё.
* * *
Шаблон для встреч один на один
Имеет смысл хотя бы раз в месяц-два проводить личные встречи хотя бы с ключевыми сотрудниками команды. Вот вам мой шаблон.
* * *
О непечатных символах в гуглодоках
В гуглодоках добавили возможность показать непечатные символы. Контрол или комманд шифт P, либо Вид → Показать непечатные символы. Может, надо кому.
* * *
Об умении сдаться
Надо сказать, что меня однажды работодатель на собеседовании здорово осадил, когда я на вопрос, что делать, если не успеваем в срок, стал рассказывать разные способы ускориться, а он сказал, что я забыл нулевой вариант — просто пересогласовать сроки, может они не так уж и прибиты гвоздями.
Ещё некоторые работодатели задают кейс, в котором всё плохо. Времени нет, бюджета нет, все сотрудники заболели, на подмену никого нет, сроки поджимают, прессуют со всех сторон. Недостаточно просветлённый пиэм начинает придумывать варианты — за свой счёт нанять фрилансеров, подсадить их кодить круглосуточно, самому поставить IDE и вспомнить навыки разработки, ещё чего-то и прочую неработающую чепуху. А правильный ответ — иногда выхода нет и надо просто сдаться и приступить к переговорам о смене ключевых параметров проекта, например, как в предыдущем абзаце, просто перенести дедлайн и доделать всё спокойно. Или изыскать дополнительные деньги.
Умение сдаться — тоже важный навык.
* * *
О промдизайне
Так как я сейчас немножко без работы, придумал себе челлендж, читать в день по книге, желательно какой-нибудь полезной или хотя бы любопытной. Пару дней назад прочёл историю Джонни Айва, выпуска 2014 г. за авторством Линдера Кани.
Долго думал. Могут ли в нашей стране появиться такие люди как Джобс и Айв и создать настолько крутые и революционные продукты? Предположим, родился бы в РФ условный Евгений Айвазов в семье специалиста по изделиям из серебра, который привил бы ему с детства любовь к дизайну. И был у него такой же талант к промдизайну и такая же страсть к этому делу.
Нашёлся бы в РФ университет, подобный Нортумбрии, в котором бы дизайн преподавался настолько же серьёзно? И главный вопрос, могла бы в РФ случиться история, в которой Евгений пришёл бы в компанию, занимающуюся промышленным дизайном, поставил там станок с ЧПУ и стал делать по сто пятьдесят прототипов внешнего вида устройства, пока не достигнет совершенства? Думаю, ему сказали бы, идите, Евгений, лесом. Мы импортируем ублюдочные, но дешёвые девайсы из Китая и продаём втридорога, таков путь.
Главным принципом Айва всегда было максимальное упрощение проектируемых устройств. Каждый винтик, каждая ручка, каждая кнопка должна быть обоснована.
Я примерно в 2016 году работал в калининградском филиале Неоланта, мы проектировали софт для одной атомной станции. Я притащил ТЗ руководителю отдела аналитики, показываю, а он говорит, предложить только те функции, о котором они просили в тендере, недостаточно, надо придумать что-то ещё. Прикрути какие-нибудь отчёты, что ли. Это мне советовал не новичок, а менеджер с сединами. И такая психология у нашего руководства сидит глубоко.
Да может и получилось бы у Евгения Айвазова. Взял бы его к себе Лебедев и дал заниматься любимым делом, пусть и в тысячу раз меньших масштабах.
Помните мемас про заказчика, который хочет, чтобы пользователь, заходя на сайт, видел своё отражение? Вебмастер сделал такую кнопку. Работает, только при включённой вебке. Забавно.
Выводы о том, какого тимлида ценит и команда, и клиент. Баланс качества и сроков, прогноз рисков и список задач, который поможет вам не стать мелким тираном.
Есть версия для мака и поддержка русского языка. Базовую версию можно получить бесплатно. Попробовал транскрибировать, получается сносно. На Windows потребуется установить дистрибутив с GitHub от самой OpenAI.
Книга настолько точно описывает распространенные заблуждения менеджеров и мифы из бизнес-литературы, что автор её прочитал с большим удовольствием и решил написать краткий обзор.
В сети есть огромное количество материалов о том, как правильно проходить собеседования на менеджера проектов, но мало кто пишет, как собеседования проводить. На что обращать внимание? Какие вопросы задавать? Как интерпретировать ответы?
Мы будем говорить о так называемом, техническом собеседовании, будем считать, что скрининговое кандидат уже прошёл. Вообще, «техническое собеседование» — это термин из сферы найма разработчиков, но почему-то собеседования с пиэмами и аналитиками тоже так называются, хотя технического в них не очень много.
Собеседования имеет смысл записывать, спросив у кандидата на это разрешение в самом начале, большинство соглашается.
Спросите, что кандидат уже знает о компании. Серьёзные люди, помимо внимательного изучения вакансии, находят сайт компании, более-менее разбираются, о чём она. Несерьёзные обычно отвечают уклончиво.
Поинтересуйтесь, как у кандидата дела с поиском работы, много ли собеседований, есть ли уже какие-то конкретные варианты, можно без подробностей.
Затем нужно рассказать о компании, похвалив кандидата, если он отметил в своём спиче правильные вещи. В подробности погружаться не стоит, кандидат, скорее всего, их не запомнит. Расскажите ключевое. Продуктовики вы или аутсорсники, какие продукты для какого рынка разрабатываете, на каком стеке, есть ли команда или её нужно собрать под себя, если есть, кто входит в состав команды. Будет ли пиэм чистым пиэмом или придётся совмещать функции аналитика или даже тестировщика.
Обычно рекрутер на этапе скрининга отсеивает большинство непрофильных кандидатов и на встречу с вами приходят уже люди, более-менее в теме. Вам решать, задавать ли совсем простые, фильтрующие вопросы, вроде: «Что такое проект» или: «Чем скрам отличается от канбана»
Ещё один типовой вопрос для отсеивания случайно прошедших скрининг нубов, что нужно делать, если не успеваем в срок. Грамотный кандидат расскажет пять-шесть методов сжатия расписания, неграмотный будет блеять про привлечение дополнительных разработчиков.
Вполне нормально попросить кандидата рассказать о себе и о своём опыте, внимательно выслушав и осознав, на что он делает акцент, что для него важно. Матёрые претенденты будут рассказывать о профильном (по отношению к вашей компании) опыте и проектах, похожих на ваш.
После знакомства можно переходить к кейсам. Возьмите несколько историй из богатой проектной практики вашей компании, в которых менеджеру нужно было принять решение, расскажите кандидату о них и расспросите, какое бы решение принял он.
Совет. Спрашивайте не «как вы это делали?», а «как вы это делали и как по-вашему это правильно делать?» Вторая форма вопроса более ценна, потому что менеджер мог неправильно действовать по указанию начальства, чтобы не потерять работу, при этом прекрасно зная, как правильно.
Спрашивать задачи про углы между часовыми стрелками, мячи в автобусе и канализационные люки, не нужно. Во-первых, это программистская тема, а во-вторых, умение разгадывать такие загадки говорит исключительно об умении разгадывать такие загадки, а не о профессиональных компетенциях.
Напоследок можете задать два диагностических вопроса. Поинтересуйтесь, в каких профессиональных сферах кандидату требуется помощь. Ещё хороший вопрос — попросить описать идеальное для него рабочее окружение, от количества созвонов в неделю, до кресла, мышки и компа, из ответов на эти вопросы также можно сделать вывод, подходит он вам или нет.
Попросите претендента задать интересующие его вопросы. Грамотный специалист обязательно спросит несколько вещей, из которых тоже можно сделать вывод, что для него приоритетно. Отсутствие вопросов — плохой знак.
Поинтересуйтесь, как скоро кандидат сможет выйти на работу, если получит оффер.
Напоследок расскажите претенденту дальнейшие действия. Будут ли ещё собеседования с другими членами команды или руководством (этим грешат крупные компании), как скоро он получит обратную связь. Поблагодарите за уделённое время и попрощайтесь. Нормальное время собеседования — сорок-пятьдесят минут, за это время можно выяснить всё необходимое.
Предположим, вы или ваше руководство пришло к выводу, что без мобильного приложения бизнес теряет прибыль и обойтись завёрнутым в какую-нибудь программную обёртку веб-сайтом никак невозможно, нужно пилить что-нибудь нативное.
У вас четыре варианта подхода к найму исполнителей.
Инхаус-команда.
Один или несколько фрилансеров.
Аутстаф команда под полным вашим контролем.
Подрядчик, которому вы поручаете работу под ключ.
У каждого варианта есть плюсы и минусы, давайте разбираться.
Инхаус команда
Создаём штатные единицы исполнителей, поручаем рекрутеру найти кандидатов в штат. Вносим им записи в трудовые книжки, платим зарплату.
Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры.
Большая ответственность ложится на рекрутера и нанимающего менеджера. Если они наймут недостаточно квалифицированных специалистов, вы потеряете довольно много денег на их зарплаты и урегулирование увольнений без суда (предполагаю, что вы работаете по белому).
Инхаус-сотрудников можно мотивировать корпоративной шизой, давить на совесть, просить переработать во имя будущих бенефитов и применять другие управленческие дарк-паттерны. Во всех остальных вариантах это будет затруднительно или невозможно.
Есть мнение, что инхаус-разработка стабильнее. Что у штатного сотрудника выше мотивация, он внезапно не пропадёт с радаров. Однако работодатели делились со мной историями, как штатный сотрудник просто переставал приходить в офис и брать трубку, даже не забирал трудовую.
Один или несколько фрилансеров
Главный плюс этого варианта — дешевизна. Вы можете найти фрилансеров на совершенно любой бюджет. Даже если у вас буквально три копейки, найдутся люди, которые выполнят заказ и далеко не факт, что некачественно.
Чаще всего, фрилансеры не требуют договор. Есть пространство для бухгалтерских манёвров с расходами на них. Нет официального оформления отношений — в ваших руках большая свобода в формировании команд и их переформатировании.
В остальном же, у этого подхода сплошные недостатки. Например, у фрилансера может быть основная работа, на которой сейчас его не слишком напрягают и у него есть время фрилансить, а через месяц ситуация поменяется. Без договора, фрилансер связан с вами только устными обязательствами и рискует только своей репутацией на данной площадке.
Ранее практиковался найм разработчиков-фрилансеров из Украины, они стоили ещё дешевле, относительно российских. Но теперь этому мешает СВО и препятствия для трансграничных переводов.
За фрилансерами крайне желательно ставить наблюдать штатного специалиста, чтобы он проводил код ревью и добивался качественного, читаемого, поддерживаемого кода. Для того, чтобы когда вам придётся фрилансера заменить, новый специалист не потребовал переписать код с нуля, а мог нормально подхватить недоделанную работу.
Аутстаф команда под вашим контроем
Находите аустаф-компанию, договариваетесь о часовых ставках и грейдах, вам предоставляют специалистов. Вы ставите им задачи, они их пилят и отчитываются в какой-нибудь таск-трекер об отработанных часах. В конце месяца аккаунт присылает отчёт, вы проводите оплату.
Достаточно гибкий вариант. Вы так же, как с фрилансерами, можете формировать и перетасовывать команды как угодно. Если не нравится работа конкретного специалиста, не нужно думать, как его правильно уволить, просто просите аккаунта его заменить.
Недостаток метода в дороговизне. Аутстаферам нужно платить специалистам зарплаты и при этом что-то зарабатывать, поэтому это самый дорогой вариант.
Кроме того, аутстаферы не несут никакой ответственности за результаты и их крайне сложно этой ответственностью наделить. Вы самостоятельно должны их менеджерить, следить за постоянством загрузки и тем, чтобы они делали только приоритетные вещи.
Подрядчик для работы под ключ
Метод подходит для не очень сложных приложений, для которых вы можете составить полное ТЗ и делегировать его производство подрядчику, чтобы он сделал его водопадом за раз, за фиксированный бюджет.
В этом случае ТЗ можно приложить к договору, чётко оговорив критерии качества продукта, который должен получиться в итоге. Возможно, подрядчик захочет написать более детализированное ТЗ и согласовать с вами, на это уйдёт дополнительный бюджет.
Возникает вопрос, как потом поддерживать получившееся приложение. Тут возможны варианты, всё зависит от изменчивости среды и потока изменений. Можно заключить отдельный договор на сопровождение с этим же или другим подрядчиком.
Также возникает вопрос, как в этом случае проконтролировать качество кода с точки зрения последующего обслуживания, развития и доработок.
На практике рассмотренные методы хорошо и правильно комбинировать. Например, нанять инхаус лидов, а для исполнителей использовать аутстаф.
Описанные ниже практики могут показаться самими собой разумеющимися для опытных тимлидов и пиэмов, давно и плотно занимающихся профессиональной разработкой ПО. Однако, попав в стартап, можно обнаружить, что горе-фаундеры забыли их внедрить. Давайте о них поговорим.
Гит
На проекте я тимлид,
В мастер пушу свой коммит,
У меня на это есть
Полный доступ в гит.
Если команда проекта состоит из вас одного, да, можно заливать код по FTP и вносить правки прямо на прод. Но уже когда вас становится двое, начинаются проблемы. Вы будете затирать код друг друга, откат из серверной резервной копии будет занимать массу времени и проч. Кроме того, в процессе залития файлов через FTP, прод будет работать нестабильно. Гит решает все эти проблемы, у вас появляется нормальная версионность, нормальный мерджинг, нормальное залитие кода в прод. Первым делом в стартапе надо внедрить гит, если его ещё не внедрили.
Код ревью
Как и в предыдущем случае, если команда из вас одного, вы сами за всё отвечаете и качество кода только на вашей ответственности. Но как только появляется второй разработчик, начинаются риски, что он будет вливать говнокод с очень странными и неочевидными программными решениями. Код ревью надо внедрять вторым делом и никогда на него не забивать, даже в экстренных случаях, когда какая-то важная функция работает неправильно, иначе вы рискуете положить прод вообще.
CI/CD
Эту загадочную аббревиатуру нужно внедрять в третью очередь, когда гит и код ревью уже заработали. Даёт великое множество профитов — возможность гибко управлять правами доступа, автоматизировать ручные действия и самое главное, возможность нормально масштабироваться. Без CI/CD в случае резкого всплеска нагрузки вам останется только развести руками.
Прозрачный процесс постановки задач
В прошлом команды зачастую проживали несколько стадий — устная постановка задач, запись на листочках, запись на физической доске, обвешивание досками всего кабинета, депрессия, переход на таск-трекер.
В других компаниях руководство грешит тем, что кидается задачами прямо в почте или в чатах, потом удивляется, почему ничего не сделано и ничего невозможно отследить. В четвёртую очередь ставим таск-трекер и принуждаем всех пользоваться им. Если руководство слишком нежное, обязываем кого-нибудь наиболее ответственного из тестирования или, в крайнем случае, тимлида, преобразовывать эти потоки сознания в тикеты.
Руководитель изрыгнул в чат баг или очередную светлую идею — ответственный сотрудник заводит тикет в таск-трекере и скидывает в чат номер. Исключений нет.
Одна задача = одна ветка в гите.
Крупные задачи нужно дробить на мелкие. А для мелких заводить отдельные ветки. Причина проста. Если вы решите вести в одной ветке 10 задач и срочно потребуется релизиться, вы не сможете это сделать, если хотя бы в одной будет критичный баг. Если вести задачи в отдельных ветках, вы совершенно спокойно зальёте 9 рабочих веток с 9 рабочими задачами и обрадуете стейкхолдеров и пользователей.
Автотесты
Вам может показаться, что продукт слишком мал и прост для автотестов. Но проблема роста потому и проблема, потому что момент роста сложности трудно заметить. А без автотестов вы постоянно будете сталкиваться с тем, что вливаемые функции ломают существующие. А когда вы станете совсем большими, можете завести выделенный отдел автотестирования.
Мониторинг ошибок
Последний, но не по важности пункт, который надо внедрять в стартапе в обязательном порядке. Ставить систему мониторинга ошибок и настраивать этот самый мониторинг. Потому что иначе вы будете узнавать об ошибках от пользователей, как правило, с очень ограниченной информацией, вроде мутного скриншота и ещё более мутного описания последовательности действий. Ещё хуже, если к вам с ошибками будет прибегать кто-нибудь из топ-менеджмента, на этом ваша карьера в этом стартапе может быстро закончиться.
Мониторинг ошибок позволяет узнавать о багах по мере появления, надо только выстроить процесс так, чтобы на этот мониторинг ответственные лица не забивали.
Вот, в целом, и все полезные практики, которые вам нужно завести в свежем стартапе чем раньше, тем лучше.
