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

Рекомендую прочитать вот эту статью. В ней ведущий рекрутер ЕПАМа Илия Чукмарова приводит свой перечень из 50 возможных вопросов. 

Мне же кажется, что 50 вопросов задавать не надо, а надо поинтересоваться следующим:

Вы аккредитованная айти-компания?

Это стало настолько важно, что hh добавил соответствующую галку в поиск.

* * *

В связи с чем открыта вакансия? Это новая должность или у меня есть предшественник? Почему он ушёл? 

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

* * *

Расскажите о составе, численности и квалификации команды.

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

* * *

Как поставлено тестирование?

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

* * *

Сколько проектов может быть в одновременном производстве?

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

* * *

Какие существуют формы отчётности? Надо ли логировать время и если надо, насколько подробно?

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

* * *

Как долго продолжается испытательный срок? 

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

* * *

Кто занимается договорной работой по проектам? 

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

* * *

В чём общаетесь, какой у вас таск трекер?

Чаще всего, это слак для внутреннего общения и телеграм для переговоров с заказчиком. Иногда встречаются Тимс или Дискорд. В качестве таск-трекера сейчас почти повсеместно джира. 

* * *

Как будем оформлять отношения?

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

После старта СВО устраиваться неофициально потеряло смысл — у вас не будет отмазочных справок.

* * *

Во сколько фактически начинается рабочий день? 

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

* * *

Как у вас организованы продажи?

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

* * *

Как вы определите, хорошо я работаю или плохо? 

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

* * *

Расскажите о темпах роста компании.

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

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

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

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

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

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

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

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

---

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

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

Тиран

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

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

Демократ

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

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

Рукастый

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

Экспериментатор

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

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

Жертва

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

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

Микроменеджер

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

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

Невидимка

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

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

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

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

Оценка задач

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

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

Статус

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

Планирование спринта

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

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

Ретроспектива

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

Демо

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

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

Дейлики

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

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

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

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

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

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