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

Пост навеяла двухнедельная работа на айти-подразделение ГК «Самолёт» в начале этого года. Там мне попытались передать команду, которой ранее руководила девушка, пришедшая в айти из юриспруденции и организовавшая работу так, как умела — то есть, замкнула на себя всё. От детальной координации каждого исполнителя до анализа продуктовых и проектных метрик, кадровых вопросов и разбора обращений из соседних подразделений (за две недели я их наловил сорок восемь). В сочетании с очень тревожным руководством, требующим ежедневной отчётности и постоянными совещаниями, каждый час, каждую минуту, это показалось мне одним из самых больших управленческих кошмаров. Такое подразделение можно перестроить, с руководством выстроить правильные отношения, но на это уйдёт неимоверное количество нервов и времени, которых у меня нет.

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

Но перед этим прочтите, пожалуйста, пост Дениса Сиденко про «управление бровями» (Линкадин под блокировкой, чтобы блок отобразился, поставьте какой-нибудь плагин с автоматическими прокси или врубите vpn):

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

Хочешь сделать хорошо — сделай сам.

Лучшего программиста делают тимлидом. Лучшего продавца — РОПом. Лучшего дизайнера — арт-директором.

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

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

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

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

Не обучать

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

Да и в конце концов, вас же никто ничему не учил, вы всё сами постигли, правильно? Чем они лучше?

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

Периодические увольнения — это тоже нормально. Люди будут увольняться, это не просто риск, это стопроцентный факт. Вы обязаны выстраивать систему так, чтобы от увольнения сотрудника, даже очень важного и квалифицированного, система не рушилась. Дублирование функций во все поля.

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

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

Давать распоряжения и инструкции только устно

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

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

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

Да, тут есть другая крайность. Можно дорегламентироваться до многостраничных мануалов, которые будет трудно воспринимать (как, например, в айти-подразделениях «Комуса»). Но в целом, и это лечится, просто не требуйте от новичков знания их наизусть, пусть ознакомятся и разок на практике их пройдут и всё получится. Читайте правило про обучение.

Не давать сколько-нибудь детальных планов

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

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

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

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

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

Не координировать людей

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

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

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

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

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

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

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

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

Команда

Небольшая команда

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

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

Команда побольше

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

Ошибки и эскалации

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

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

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

Измерения

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

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

Критика

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

Вот задача на реализацию функции. Вот требования. В требованиях ясно сказано, блок должен быть адаптивным. В макете есть адаптив. Ты оценил с учётом адаптива. Однако адаптива сейчас нет, хотя ты сдал задачу на тестирование. Скажи, пожалуйста, сколько у тебя уйдёт времени, чтобы реализовать адаптив?

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

Страх — плохой мотиватор. Будьте доброжелательны и конструктивны с командой.

Руководство внедряет херню

Что делать, если ваше руководство приняло решение о внедрении какой-то ненужной административной херни, из-за которой у ваших подчинённых прибавиться бесполезной работы? Считается очень плохой идеей сообщить новость с посылом «опять эти наверху придумали херню, я против, но что делать, будем внедрять». Мысль о том, что внедряют херню нужно озвучивать на совещании с руководством, когда идёт обсуждение, внедрять или не внедрять. Если уже внедрили, вы не имеете права саботировать в какой-либо форме. Я обычно сухо сообщаю команде только факт принятия решения, не сопровождая его никакими оценками. Да, страшная правда в том, что нам всем приходится делать ненужную херню, это реальность. На госслужбе этого очень много, в бизнесе меньше, но тоже есть. Я сбрасываю напряжение, превратив ситуацию в кейс и описав её в обезличенной форме в социальных сетях или в этом блоге, но не сразу, а спустя какое-то время, когда эмоции поутихнут. О технической херне речь будет ниже.

Сообщения на выходных

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

1-2-1

Совершенно необходимо время от времени устраивать 1-2-1 с сотрудниками, особенно если у вас большая команда. Тут главное правило — не вызывайте людей ВНЕЗАПНО, назначьте встречу заранее, будет здорово, если напишете тезисы повестки. Когда я работал на своей первой более-менее серьёзной руководящей должности, босс в рандомные моменты времени вытаскивал меня из кабинета, усаживал на диван и устраивал стихийный 1-2-1. Да, это лучше, чем полностью забить на эту практику, но будьте человеком, дайте сотруднику время подготовить ответы на ваши вопросы. Например, однажды босс сказал, что я слишком часто беру дни удалённой работы, почти каждую неделю и это плохо. Правила компании не регламентируют частоту таких дней, но это плохо. Оставим комизм ситуации за скобками, обратимся к фактам. Если бы у меня была возможность подготовиться, я бы выгрузил данные о пребывании сотрудников в офисе и доказал этому человеку, что по времени пребывания нахожусь в середине списка, присутствуя в офисе совершенно нормальное количество времени.

Токсики в коллективе

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

Авансы

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

Оффлайн-встречи для удалёнщиков

Если вы удалёнщики, собирайтесь время от времени лично (да, придётся оплатить командировки), поработайте, попроектируйте что-нибудь с маркерами у доски, съешьте пиццу, выпейте пива.

Отношение к вопросу, вместо ответа

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

Заказчик

Главные мысли

Основная мысль, которую нужно донести до заказчика в самом начале общения — что мы в одной лодке, у нас одна цель, мы на одной стороне, у нас только win-win.

Заказчик — эксперт в области своего бизнеса. Вы и ваша команда — эксперты в области решения проблем при помощи разработки ПО.

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

Нужно определиться, в каком стиле вы будете общаться с заказчиком. Мне нравится «на вы с маленькой буквы». То есть, держим определённую дистанцию, не переходим на панибратство. С эмодзи нужно быть осторожным, они на разных платформах отображаются по-разному, вас могут не так понять. Один раз стал свидетелем того, как коллега отправил заказчику мем: «Подтверди первичную оценку, будь мужиком, блеать». Оценку подтвердили, но в другой ситуации порыв могли не оценить.

Проговариваем, чего хотим

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

Каналы коммуникации

Нужно проговорить и закрепить каналы коммуникации. Считаю нормальным наличие трёх каналов:

• Имейл-переписка для констатации официальных моментов. Если что, её примут в суде, если в договоре закреплены официальные имейл-адреса для такой переписки и она велась с них.
• Мессенджер для быстрых коммуникаций. Обычно это телеграм. Избегайте ситуаций, когда одни представители общаются с вами в телеграме, другие в вотсапе, договоритесь об одном мессенджере.
• Звонилка. Нужно, чтобы поддерживала видеосвязь, демонстрацию экрана и запись звонков. Обычно это zoom.

Имена

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

Письма

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

Соблюдайте структуру письма. Например:

• Приветствие. Обязательно обратитесь по имени к тому, кому пишете. Это нужно делать, даже в ответных письмах. Кто-то ставит после имени восклицательный знак, я предпочитаю запятую.
• Суть разговора.
• Вопрос или призыв.
• Ваша подпись. Тут чаще всего действуют корпоративные стандарты, но подпись должна быть 3, максимум, 4 строки.
• Как связаться, кроме почты.

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

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

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

Созвоны

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

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

Эмоции

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

Однозначность

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

Экспертность

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

Опоздания

Опаздывать нельзя. Если случился форсмажор, попросите заказчика о переносе встречи. Этому я научился ещё на самой первой разъездной работе. Если пообещали приехать в три часа дня, но за пару часов позвонили и сказали, что приедете в четыре, никто не будет ругаться, но если молча приедете в четыре, вас проклянут.

Не делайте слишком длинные встречи. Дольше сорока минут трудно сохранять фокус.

Фиксация договорённостей

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

Если записываете встречу, попросите у заказчика разрешение на это. Считаю запись встреч хорошей практикой.

Календарь

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

Споры и дискуссии

Никогда не оспариваем мнение заказчика. Возьмите за правило подзаголовок этого блога — пиэм разъясняет, предостерегает, рекомендует. Чтобы переубедить заказчика, оперируйте фактами. Прозвучит парадоксально и на первый взгляд, противоречиво, но и делать всё, что требует клиент, тоже нужно не всегда. Клиент не всегда прав, иногда он требует вещи, которые ему навредят и ваша работа — аргументированно это ему объяснить. Так и говорите: «Есть пять фактов, которые говорят о том, что это плохая идея… Кстати, можно добиться примерно запрошенного результата вот таким путём…»

Никогда не перебиваем.

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

Не врём. И не берём на себя обязательства, которые выполнить не сможем. Это особенно важно.

Переговоры с участием руководителя и коллег

Если в переговорах участвует ваш руководитель — впрягаетесь за него, поддерживаете его позицию и наоборот, он должен поддерживать вас. Претензии выскажете друг другу после звонка. Это же касается ваших подчинённых. Выскажете им после своё неодобрение, если необходимо, разнесёте каждого предметно на 1-2-1. Но при клиенте у вас должно быть взаимопонимание с руководителем и коллегами.

Серьёзные проблемы

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

Прочее

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

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

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

Руководство

Собеседование

Работа с руководством начинается с собеседования. И если в начале карьеры имеет смысл браться за любую возможность приобрести коммерческий опыт, в дальнейшем советую избегать дураков и мудаков. Как выявить мудака-руководителя на собеседовании — тема отдельной статьи, но пока можете прочитать статью про красные флаги. Честное слово, много вы с ними не заработаете, а нервы себе попортите основательно. Мне начинает казаться, что помимо вопросов о компании, стоит спрашивать и более фундаментальные вещи, вроде того, как он ставит задачи подчинённым и, не услышав слово SMART, заканчивать встречу досрочно.

Неудачная работа

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

Держать в курсе

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

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

Результаты

На госслужбе главный залог успешной карьеры — работать так, чтобы у вашего начальника не болела из-за вас голова. В бизнесе этого недостаточно, нужно ещё и давать постоянный, повторяемый результат в работе. Если в компании не внедрено измерение результата, всё это может быть для руководителя неочевидно, результаты надо пиарить. Рассказывайте о них на 1-2-1, а если таковые не проводятся, пишите хотя бы обстоятельное письмо раз в квартал. Помните, что руководитель очень занят и автоматически информацию о ваших успехах не получает.

Обращения через голову

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

Обсуждение и оспаривание распоряжений

Можно ли обсуждать распоряжения руководителя? В театре, например, действует правило. Актёр может предложить свои идеи по тому, как играть эпизод, но только после того, как сделает вариант, который требует режиссёр. В армии за неисполнение приказа могут серьёзно наказать. Но мы не в армии и не в театре, мы занимаемся созданием и поддержкой зачастую очень сложных программных продуктов, в которых реализация неправильного решения может привести (особенно, в высоконагруженных системах) к простою десятков тысяч людей и многомиллионным потерям. Поэтому, если вас просят сделать программную херню, оспаривайте, но только не в присутствии других сотрудников. Попросите руководителя о личной встрече и всё обстоятельно аргументируйте.

Случай из практики. Мой руководитель и ведущий технический эксперт компании собеседовали претендента на должность SQL-разработчика. Они колебались и решили задать финальный вопрос. Вопрос был технический, очень сложный, касался поведения механизмов индексации SQL-сервера в определённой ситуации. Претендент дал ответ. Они сказали, что это не так и они с ним прощаются. Претендент пошёл домой, инсталлировал на свою машину SQL-сервер нужной версии, воссоздал кейс, запустил индексацию, понял, что был прав, сделал скриншоты и написал шефу письмо. Его взяли на работу. В работе он оказался полным клоуном и не создал ничего, кроме головной боли, но это уже совсем другая история.

Стоп-фразы

Пожалуйста, не произносите при руководителе фразу: «Мне за это не платят». Уверяю, вам платят достаточно.

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

Не надо говорить: «Это не моя вина», замените на: «Я сделал выводы и сделаю всё, чтобы ситуация не повторилась».

Не надо говорить: «Я не буду это делать, потому что не успею». Замените на: «У меня вот такой список дел, дай мне приоритеты».

Критика

Научитесь не быть соевой снежинкой и нормально воспринимать критику. Но есть нюанс. Я, например, не прислушиваюсь к мнению людей, на которых не хочу быть похожим.

Деньги

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

Внимательность к цифрам

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

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

О следующем уровне

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

В 2008 у меня всё было довольно грустно. За плечами технический вуз, год невнятного опыта одинэсником, полгода опыта преподавателем, в наличии полное нежелание калининградских работодателей брать меня на какую-либо должность (удалёнки тогда не было даже близко).

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

Грустный еду с собеседования (офис был в ебенях), разговорился с соседом по автобусу. Он спросил, куда я ездил в эти ебеня, я рассказал, что на собеседование. А он говорит, что задолбали эти собеседования, у него решительно нет денег, чтобы на них ездить, почему не могут просто взять на работу. И я как-то очень чётко осознал, что есть ступенька ниже и этих ступенек ещё очень и очень много.

* * *

О контроле

У начинающих руководителей часто возникает вопрос. Вот у меня есть подчинённый, он выполняет какие-то задачи, в конце периода скидывает отчёт. Я что, должен каждую выполненную им и указанную в отчёте задачу лично проверить и верифицировать?

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

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

* * *

О багах

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

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

Почтовый клиент Mail, который всегда был вылизанным, выдаёт вообще, несусветное, я даже это нормально объяснить словами не могу. В списке писем имена пользователей в некоторых письмах «трусит». Я, конечно, подумал, что в пицце с грибами попались не те грибы, снял скринкаст, показал сисадмину, он тоже это видит.

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

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

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

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

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

* * *

О валюте

В связи с преодолением рублём очередного дна.

Человек, ничего не понимающий в экономике: Да нет никаких механизмов формирования курсов, просто евреи в Нью-Йорке цифры рисуют.
Человек с экономическим образованием, работающий в этой сфере: Экономические механизмы сложные, их много, там сдержки и противовесы, это всё нужно долго изучать для минимального понимания.
Человек, имеющий прямое отношение к экономике, уровня топ-менеджера ЦБ: Да нет никаких механизмов формирования курсов, просто евреи в Нью-Йорке цифры рисуют.

* * *

Об OLE

Одной из вещей, больше всего удививших меня в самом первом компе, был реализованный в Windows механизм OLE. Object Linking and Embedding. То есть, вы можете вставить в документ файл любого типа, лишь бы он поддерживал этот механизм, файл будет слинкован с документом, изменения в файле будут отображаться в документе. Это казалось прям пушкой.

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

Будет здорово, если вы расскажете, как использовали OLE, а позднее ActiveX для каких-то более продвинутых вещей.

* * *

О мотивации

Пересматривал вчера «В Бореньке чего-то нет», понравился один момент. Режиссёр (Виторган) рассказывает своему другу-сценаристу (Демидов), что у него есть знакомый, производитель мебели. Не ширпотреба, а вполне нормальной мебели. И однажды этот мебельщик купил себе дом. Режиссёр его спрашивает, а ты мебель в этот дом, своего производства поставишь? А тот отвечает, нет, конечно, я хочу, чтобы у меня дома была нормальная мебель.

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

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

* * *

О боязни рисков

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

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

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

* * *

О важности критики

Я когда-то очень любил фразу Королёва: «Критикуешь — предлагай. Предлагаешь — делай. Делаешь — отвечай», но чем дальше, тем больше мне кажется, что возможность критиковать, не предлагая решений, это норм.

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

* * *

О важности советов

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

Запросить совет или второе мнение по проектным затруднениям вполне норм и зрелые пиэмы этого не стесняются.

* * *

О навыках постановки задач

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

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

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

* * *

О том, как важно быть активным пользователем своего продукта

Видел интервью, в котором Якубович рассказывает, что понятия не имеет, что такое «Поле чудес», так как ни разу его не смотрел, кроме того, в его семье запрещено эту передачу смотреть и обсуждать.

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

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

* * *

О стоимости владения сотрудником

Я ранее писал о стоимости владения кодом. Если вы решили задачу написанием нового кода, помимо стоимости создания, придётся оплачивать и владение этим кодом, а это много. Сегодняшняя мысль — есть «стоимость владения сотрудником».

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

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

* * *

О важности навыка

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

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

* * *

О специализации

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

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

Я за специализацию с разумным T-shape.

Помню, как мой препод в институте сказал: «Ты можешь иметь хоть 10 высших, только что с того? У тебя в башке будет такой винегрет, что ты будешь идиотом во всём». Глядя на нашего плотника, художника, лётчика, подводника, музыканта и писателя, понимаю, как прав был профессор.

* * *

О замораживании процессов

Оказалось, что список процессов в виндовом диспетчере задач можно «заморозить», чтобы процессы не скакали и их можно было спокойно выбирать. Для этого достаточно нажать Ctrl.

Тайным знанием поделился инженер Microsoft Дейв Пламмер, который эту функцию и придумал.

* * *

О феминитивах

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

* * *

Об аэропортофобии

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

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

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

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

Ну и последний момент, который раздражает меня в авиаперелётах — невозможность иметь с собой какое-либо оружие. Даже баллончик CS, абсолютно законная штука, не может быть провезён самолётом, даже в багаже. Антитеррор во все поля, конечно, но чувствуешь себя голым. К счастью, на внутренних перелётах разрешают иметь при себе тактическую ручку, если она не особо стрёмного вида (но в некоторые страны Европы и её заставят выкинуть).

* * *

О зарплате

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

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

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

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

Считаю такой эволюционный подход к запрашиванию зарплаты, достаточно экологичным и разумным.

* * *

О фичеризме

Давным-давно корифеи копирайтинга начали говорить — никакого «фичеризма» в рекламных описаниях продукта! То есть, не надо описывать функции продукта в столбик, расскажите лучше, какие проблемы он решает. Apple вообще, продаёт не столько продукты, сколько стиль жизни.

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

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

Не изгоняйте фичеризм окончательно, пожалуйста.

UPD: После обзоров телик, кстати, покупать раздумал. Пишут, что звук не такой уж премиальный; при расшаривании экрана на него, тормозит даже по кабелю; нет 120 гц.

* * *

О безопасности

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

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

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

* * *

О быстром улучшении работы компании

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

1. Добился бы максимально возможной специализации исполнителей. Реализовывать вьетнамский вариант, когда за каждую операцию отвечает отдельный вьетнамец за миску риса и сникерс, конечно, не надо, но и от режима «все делают всё, но никто толком не отвечает за конкретную задачу» надо избавляться первым делом.
2. Добился бы дублирования исполнителей для максимально возможного количества функций. Каждую операцию должны уметь делать, как минимум, два человека на случай отпусков, болезней, отгулов и внезапных увольнений. Люди также должны быть замотивированы подменять друг друга в таки ситуациях не только корпоративным духом. Хорошо работает матрица компетенций.

* * *

О перелётах

Прилетел в Ижевск с однодневным визитом. Прямого рейса не нашлось, впервые в жизни летел с пересадками. Мысли для других командированных:

1. Хорошие наушники, обязательно с качественным шумодавом — наше всё.
2. Всем плевать на расписание. При выборе рейсов для полёта с пересадкой, закладывайте на пересадку не менее 4-5 часов (при условии, что вам не нужно менять аэропорт), опоздание на час-полтора, похоже, в авиации, вообще, не считается за косяк.
3. Идите на регистрацию сразу после её открытия, в Шереметьево адские очереди на регистрацию.
4. При формировании сметы для работодателя, побольше закладывайте на такси с учётом высокого спроса.
5. Хорошая, дорогая зарядка с четырьмя портами — прекрасное вложение денег. Поставить на зарядку одновременно ноут, смартфон, наушники и четвёртый гаджет (умные часы, например, но у меня это фонарик-павербанк) очень удобно.

* * *

О единомышленниках

Помните, как Хаус во втором сезоне уволил Бозли за то, что тот озвучивал его мысли? У Хауса была крайне интеллектуальная работа и чтобы выполнять её успешно, ему были нужны люди, мыслящие принципиально иначе, чем он, чтобы его дополнять и усилять.

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

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

* * *

О правде

Булгаков, устами Иешуа, говорил, что правду говорить легко и приятно. Насколько приятно после этого искать новую работу, он не говорил.

* * *

О важности логов

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

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

Определённо бесит ситуация, когда у пользователя ошибка, он звонит в саппорт, там у него выясняют шаги воспроизведения, пытаются воспроизвести, а ошибка не воспроизводится.

Логи ошибок мастхэв.

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

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

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

👊 Закрытый кулак означает сильное несогласие или полное «нет».

👆 Один палец указывает на огромные сомнения по поводу предложенного решения. 

✌️ Два пальца означают, что по решению есть сомнения, которые необходимо обсудить, прежде чем принять решение.

🤟 Три пальца свидетельствуют о том, что вы не против попробовать, но есть пара моментов, которые нужно учесть после принятия решения.

🤘🤘 Четыре пальца означают согласие, но с некоторыми мелкими сомнениями.

🖐️ Пять пальцев демонстрируют полное согласие, энтузиазм по поводу решения, отчётливое «да».

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

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

Я всё же противник голосований, но если голосовать — то методом Fist to Five.

Ранее у меня был пост о проектных ролях. Этот пост — продолжение темы. В нём я хотел бы поговорить подробнее о команде проекта, кто в неё входит и что делает. Состав команды меняется от компании к компании, от проекта к проекту, я постараюсь перечислить максимум специальностей. Писать буду взгляд на каждую должность с позиции менеджера проекта.

Менеджмент

Менеджер продукта

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

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

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

Если вы пиэм, продакт, как правило, не является вашим руководителем, скорее заказчиком.

Аккаунт-менеджер

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

Занимается тем, что уменьшает количество вашего общения с заказчиком, беря его на себя. Часто берёт на себя оформление различных юридических документов при поддержке юристов. Поддерживает с заказчиком хорошие отношения, часто допродаёт услуги (иногда не посоветовавшись с вами). Если аккаунт технически подкован, ему можно делегировать встречи по статусу проекта, но я бы рекомендовал делать это самостоятельно.

Эйчар

Эйчары бывают как в продуктовой, так и в заказной разработке.

Занимается тем, что облегчает вашу работу с кадрами. Хорошему эйчару можно делегировать изрядную часть процесса найма сотрудников. В идеале можно будет скинуть ему требования к кандидатам и временные слоты, в которые вы и ваши коллеги будут готовы проводить собеседования, он сделает всё остальное.

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

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

Технический директор

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

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

Разработчики

Тимлид

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

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

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

Фронтенд-разработчик

Фронтенд-разработчики встречаются в веб-разработке. В крупных командах есть разделение на верстальщиков и именно фронтенд-разработчиков, но чаще верстает фронтендер.

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

Делает он всё это, как правило, на JavaScript. В чистом виде JS используется редко, чаще применяется один из JS-фреймворков, например React, Vue или Angular.

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

Неизвестный автор

Бэкенд-разработчик

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

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

Хорошие бэкендеры владеют несколькими языками программирования: C++ или C#, PHP, Python и фреймворками, которые сильно облегчают им бэкенд-разработку. В случае, например с PHP, это Laravel или Symphony, для Python популярен Django.

Если нет девопса (о нём ниже), чаще всего вопросами гита и развёртывания тоже занимается один из бэкендеров.

Мобильный разработчик

Обитают в компаниях, занимающихся разработкой приложений для смартфонов. Рыночек порешал так, что фактически осталось две платформы — Android и iOS. Соответственно, разработчики делятся на три группы — андроидщики, айосники и специалисты по кроссплатформенной разработке.

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

Айосники обычно пишут либо на Swift (чаще), либо на Objective С (реже). Андроидщики — на Java или более новом Kotlin.Технически подкованные ведроводы, пищущие особо сложные приложения или игры, используют C/C++

У специалистов по кроссплатформе всё сложно.

У вас уже наверняка пошла голова кругом, а понимания что выбрать, так и не появилось. Давайте представим простой список вопросов, который вам поможет:

Должно хоть как-то работать на любом устройстве? Выбирайте HTML как основу

У вас есть «встроенный» веб-разработчик или вы просто хотите быстро и просто попробовать мобильное приложение в деле? Тут можно рекомендовать Cordova/HTML или PWA;

У вас есть собственная CRM-система и поддерживающий ее C#-разработчик? Берите Xamarin;

Вы «хотите попробовать», но надо сделать всё красиво и модно? Смотрите в сторону React Native или Flutter.

livetyping.com/ru/blog/na-chem-pisat-krossplatformennye-prilozhenija

Quality assurance

Мануальный тестировщик

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

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

Неизвестный автор.

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

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

Когда-то путь тестировщика считался самым простым способом входа в айти. В 2022 требования к ним сильно выросли, современный тестировщик должен уметь развернуть на своём компе ветку разработчика, постучаться в API при помощи Postman или Swagger, отлично уметь пользоваться консолью разработчика в браузере и не только в Хроме, а вообще во всех, уметь составить запрос к БД и многое, многое другое.

Самые системные и коммуникабельные тестировщики становятся лидами тестирования и начинают относиться уже больше к менеджменту.

Тестировщик-автоматизатор

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

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

Всё переплетено в единый моток
Нитяной комок и не ситцевый платок
Перекати-поле гонит с неба ветерок
Всё переплетено, но не предопределено

Oxxxymiron о монолитной архитектуре

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

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

Пишут автотесты они на скриптовых языках, прежде всего на Python и JS. Используют массу инструментов, например, Selenium и Protractor.

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

Дизайнеры

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

Функция UX (User Experience) ближе к аналитикам. В рамках этих задач дизайнер определяет, как будет работать интерфейс, его логика. Как сделать, чтобы интерфейс был максимально простым, не вызывал у пользователя желание обратиться в саппорт.

Функция UI (User Interface) уже чуть более «творческая». В рамках этих задач дизайнер определяет, как будет выглядеть интерфейс, его внешний вид. Эти функции неотделимы.

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

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

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

Аналитики

Бизнес-аналитик

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

Этот специалист способен взять на себя всю работу с требованиями (однако вам всё равно нужно их рецензировать), сильно облегчив вашу жизнь, потому что если компания экономит на аналитиках, с требованиями работать вам.

Ценны аналитики, разбирающиеся в предметной области проекта, их польза сильно возрастает, но в целом, они универсальны и умеют разбираться в неизвестных предметных областях.

Основным инструментом аналитика является его аналитический мозг. Остальные специалисты тоже используют мозг, но не так активно, по большей части заменяя его гуглом, аналитик же мыслит много, глубоко и разлаписто. Из технических инструментов эти ребята используют Confluence (в модных стартапах чаще Notion), всевозможные рисовалки бизнес-графики для диаграмм, интерактивные доски вроде Miro.

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

Системный аналитик

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

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

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

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

Сисадминская братия

Системный администратор

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

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

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

В целом, они как электрики, вы с ними будете взаимодействовать редко, но без них жить невозможно никак.

Девопс

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

Эти ребята могут разворачивать процесс непрерывной интеграции и развёртывания при помощи разных инструментов — Git, Docker, Kubernetes, уменьшая тем самым головную боль программистов. Автоматизируют процессы в Jira, уменьшая головную боль всех остальных участников процесса и повышая связность системы. Также настраивает мониторинг всех развёрнутых контуров, контролирует работоспособность.

В разработке высоконагруженных приложений, девопсы бесценны.

Администратор баз данных

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

Помогает в проектировании сложных баз данных, занимается оптимизацией готовой БД, организует грамотное архивирование и восстановление в случае аварии, делает разграничение доступа к БД.

Чаще всего же на dba экономят и всё это делает девопс или сисадмин.

Прочие специалисты

Контент-менеджер

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

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

Особенно весело, когда на сайте часть информации сделана средствами CMS, часть хардкодом и нужно поменять и то, и то.

Маркетолог

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

Например, вас могут попросить реализовывать нетипичный интерактивный элемент на сайте, лендинг (обычно по готовому дизайну, с чёрным фоном, конечно же), современный маркетолог может запросить ещё и телеграм чат-бота.

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

Технический писатель

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

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

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

Чаще на техписе экономят и инструкции пишет либо кто-то из аналитиков, либо вы.

Специалист по информационной безопасности

Нужно чётко разделять СБ и ИБ, это разные вещи. СБ — это в большей степени оффлайновая служба. В неё входят вахтёры на входе, всевозможные охранники и люди, делающие пробив по разным базам кандидатов на ответственные должности в компании. С ними вы контактируете один раз, при трудоустройстве. В американских фильмах ещё часто показывают, как уволенный сотрудник покидает офис с коробкой личных вещей в сопровождении СБшника, у нас такого никогда не видел.

ИБ — это уже чисто айтишники.

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

В общем, с этими ребятами надо дружить.

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

Изначально модель содержала forming, storming, norming, performing. Через 12 лет её дополнили (при участии Мэри Энн Дженсен) пятой стадией, adjourning. Первая стадия начинается с момента формирования команды, последняя заканчивается успешным завершением проекта и расформированием команды. На мой взгляд, мини-версию этой модели команда также проходит при назначении нового менеджера. 

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

Forming

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

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

Также на постановочных встречах надо проговорить основные пункты регламента работы, структуру управления (если предполагается несколько начальников) и какая нужна отчётность. 

Storming

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

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

Штормить может долго, но если члены команды и менеджер адекватные, этот процесс не занимает дольше месяца. 

Norming

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

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

Performing

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

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

Adjourning

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

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

—

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

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

Если загуглить слово «микрокоманда», поисковик возвращает множество статей про устройство микропроцессоров. Я хотел бы рассказать о немного другой микрокоманде — практике группового подхода к разработке. 

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

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

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

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

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

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

---

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