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

Меня зовут Анастасия Абрашитова, я из древнего вымирающего племени десктопных разработчиков. Когда‑то писала программы для десктопов, под Винду, на C# и даже с Windows Presentation Foundation, работала в продуктовой и инфраструктурной разработке Лаборатории Касперского. Сейчас я работаю в Yandex Platform Engineering, руковожу службой инструментов репозитория, отвечаю за счастье разработчиков Яндекса при работе с монорепозиторием. Также у меня есть канал для начинающих руководителей — «Записки из горящего дома«. Может быть моя статья не будет особо полезна тем, кто давно работает во внутренней разработке, потому что вы всё это знаете — материал лишь отзовётся болью узнавания. Но я надеюсь, что тем, кто в этой области недавно или только рассматривает её для своей карьеры, будет полезно и интересно.

Общее коммуникационное пространство

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

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

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

А как выглядит коммуникация во внутренней разработке? Здесь происходит что-то такое:

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

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

Минусы общего коммуникационного пространства

Как с этим хаосом жить и к чему он приводит? Конечно, к целому ряду минусов.

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

• Сложнее строить work-life balance. Если в 9 утра в субботу начинают звонить на личный телефон, а в 1 ночи писать в личный Telegram, и вы на это ведётесь и начинаете отвечать, то work-life balance естественно идёт на дно.

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

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

Саппорт во внутренней разработке

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

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

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

Формируем каналы саппорта

Для начала нужно выбрать фиксированный канал, где вы будете отвечать. Это может быть что угодно, в зависимости от ваших потребностей: общий почтовый ящик, чат в мессенджере с автоматизацией или без, проект в трекере, QnA-система типа Stack Overflow, 1 линия саппорта и прочее. Можно выбрать под свои нужды всё что угодно. Что при этом стоит учитывать?

Масштабируемость

Плох тот солдат, который не мечтает стать генералом. И плох тот руководитель проекта, который не мечтает вырастить своих пользователей в 10 раз. Если сегодня 20 пользователей, то завтра, возможно, будет 200. Если сегодня к вам приходят за саппортом 2 человека в день, то завтра 20 будет приходить. Если раньше для двоих подходил чатик в Telegram, то для двадцати человек в чате будет просто мешанина. Станет совершенно непонятно, кто, кому, на что отвечает и что вообще происходит. Поэтому нужно выбирать масштабируемые каналы.

Возможности переиспользования

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

Интеграции с базой знаний

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

Приватность вопросов

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

Люди спокойно так себя ведут, если у вас какой-то приватный канал, например, почта. О том, что человек задал какой-то вопрос, знает только он и тот, кто ему отвечает — больше никто не видит.

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

Мы однажды заменили почту на QnA-систему и сократили поток саппорта в 10 раз. Правда через какое-то время люди нашли лазейку и 20% вернулись заводить необдуманные вопросы как баги. Тем не менее поток саппорта сократили в 3 раза и это был очень заметный успех.

Анонимность ответов

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

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

Измеримость

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

Формируем процессы саппорта

Что ещё нужно учесть? Зафиксируйте, кто отвечает на саппорт. Тут возможны самые разные варианты в зависимости от потока саппорта, его срочности, трудоемкости, требующихся действий. Вот стандартные варианты, кто может отвечать:

• Любой, у кого есть время. Самый расслабленный вариант, когда отвечает тот, у кого есть время. Ведь часто бывает, что времени нет ни у кого и никогда.

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

• Тимлид или технический менеджер. Приемлемый вариант, когда поток небольшой.

• Ответственный за область. Такой вариант тоже встречается, особенно если знания в команде сильно сегментированы.

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

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

Есть ещё несколько граней, которые нужно нащупать, например:

• грань между саппортом и багфиксом

Саппорт — это оперативная помощь. Она подразумевает, что вы прямо здесь и сейчас решаете человеку проблему. Иногда можно увлечься и очнуться через 4 часа в дебаггере, пытаясь что-то разобрать. Здесь нужно договориться до каких-то фиксированных правил для всей команды о том, что такое саппорт, а что багфикс. Например, если вы предложили человеку workaround, завели work item, то это уже переходит в раздел багфикса. Нужно задавать какой-то бюджет того, сколько можно потратить времени на такие оперативные разборки.

• Перенаправление людей в канал саппорта

Ещё одна грань когда нужно перестать общаться с человеком в личном канале и отправить его в канал саппорта. Это возможно сделать сразу, через 5 минут или через 10. Это всё тоже нужно обязательно проговаривать с командой, потому что вы тимлид. У вас в job description есть техника конструктивного отказа, вы должны уметь говорить НЕТ так, чтобы никто не обиделся и было понятно, что с этим НЕТ делать. А вот ваши разработчики совершенно не обязаны это уметь. Поэтому нужно научить их, иначе они начнут отвечать даже тем, кто мимо всех процессов не вовремя пришёл. На этом месте весь ваш саппорт развалится, а сговорчивый Вася снова прославится.

• Перенаправление людей в документацию

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

Общее коммуникационное пространство: плюсы

Плюсы в коммуникационном пространстве тоже есть:

1. Вы тоже так можете =/. Этот плюс сомнительный, поэтому стоит перекошенный смайлик. Но, если вы считаете приемлемым и вам хочется позвонить заказчику в 9 часов утра в субботу, потому что он вас DDOS-ит, вы можете это сделать — выбирайте сами.

2. Общение быстрее, каналы прямые и легко заменяемые. Многообразие каналов коммуникации можно использовать и для собственной эффективности и пользы. Когда между вами и пользователями стоит менеджер по продажам или проектный менеджер, то все вопросы ходят через него. Иногда это скорость голубиной почты. А тут можно прийти и сказать: «Давай я сяду за твой компьютер, разберёмся за 10 минут, что у тебя происходит» или попросить скинуть логи и сказать: «Ага, нажми здесь, теперь скинь ещё раз логи». Потом уже где-то в Telegram можно продолжить оперативное общение и быстро всё порешать.

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

Общее организационное пространство

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

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

Эскалации

К сожалению, мир не всегда бывает хорошим и правильным, поэтому начинают происходить странные вещи:

И вот вы уже обнаруживаете чьего-то большого начальника, который над вами нависает, давит своим авторитетом и пытается добиться какого-то решения — это очень неприятно! Но это ещё не самое худшее, потому что может быть так:

Или так:

Когда этот большой начальник навис не над вами, а над вашим большим начальником. А он, в отличие от вас, ни сном, ни духом, почему всё именно так должно быть, почему это правильно. В этот момент руководитель вас защитить не может, поэтому в лучшем случае сверху вниз полетит «Разберитесь!», в худшем, решение о том, как всё исправить и переделать.

Бывает ещё так:

В этом случае совершенно точно человек наверху примет решение, а вам остаётся жить с этим решением. Как бороться с эскалациями?

• Предотвратить

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

Но это не всегда помогает, что делать с самими эскалациями?

• Смягчить!

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

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

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

Общее организационное пространство: плюсы

1. Вы тоже так можете =/. Опять сомнительный плюс. Если вам почему-то нравятся эскалации или у вас в компании так принято, это портал в ад, который работает в две стороны. Вы тоже можете пойти к своему начальству и начать что-то эскалировать.

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

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

Общее социальное пространство

Пространство сотрудников какой-то компании — это маленький социум. А там, где есть общественность, есть общественное мнение.

Частным случаем общественного мнения будет ваша репутация - репутация вашего продукта или сервиса, вашей команды, лично ваша репутация. Конечно, желательно иметь хорошую репутацию, а не плохую. Я знаю сервисы, руководителей и команды, у которых плохая репутация. Это им очень здорово вредит. С одной командой, которая когда-то “прославилась” плохой работой, я работаю уже год. Они совершенно нормальные — команда хорошая, сервис стабильный, надёжный, руководитель открытый и всегда помогает. Но нет — повсюду бытует общественное мнение, что эта команда очень плохая и работать с ними нельзя. Даже меня иногда спрашивают, зачем я с ними работаю. Их плохая репутация отражается на репутации моего продукта, ведь мы связаны. Сложивлееся мнение сложно преодолеть, нужно делать долгие и осознанные усилия. Если их не делать, то от вас просто будут бегать, как от чумы.

Также в социуме всегда есть лидеры мнения. Они влияют на мнение окружающих серьёзнее, чем все остальные. Это данность, которую нужно принять и научиться использовать в своих интересах. К счастью, у нас не ТикТок, а IT, поэтому opinion maker-ы обычно — это люди, которые выделяются глубокой компетенцией, характером, неожиданными и смелыми решениями. К этим людям стоит прислушиваться, спрашивать фидбэк о том, что им нравится, а что нет в вашем продукте. Можно показывать early preview того, что собираетесь делать. Плюс состоит в том, что если этим людям действительно понравится, то они помогут донести это до пользователей. А если не понравится, то есть смысл хотя бы прислушаться к тому, что они говорят.

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

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

Как работать с общественным мнением

Рассказывайте свои новости

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

Будьте открыты к фидбэку

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

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

Научитесь собирать положительный фидбэк

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

Поэтому если вы хотите видеть не перекос в сторону обиженных, а более реальную выборку фидбэка, нужно прилагать усилия к тому, чтобы пользователи его оставляли. Завести какую-то форму для фидбэка, быть к нему открытым, говорить спасибо и прислушиваться к тем, кто его оставляет. Можно завести баннер: «Мы поменяли фичу — как тебе, ОК, не ОК?» или проводить CSI опросы, только не часто. Можно максимально разнообразно собирать свой фидбэк, и не только негативный.

Мнение побеждается фактами

Мнение, даже общественное — это оценочное суждение, и оно побеждается фактами. В вашем продукте это метрики, статистика, эксперименты. Ими и нужно оперировать.

Например, к вам приходит разгневанный пользователь и говорит:

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

Отвечаем:

 — Мы сейчас подняли статистику, посмотрели на метрики — у нас 50 перцентиль 0,2 секунды (к примеру), а 90 перцентиль 0,4 секунды — всё нормально. У тебя что-то нестандартное происходит, давай разбираться, почему.

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

Общее социальное пространство: плюсы

• Положительное общественное мнение — огромная сила

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

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

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

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

• Плохая репутация — не конец света

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

• Огромный простор для custDev и UX-исследований

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

Общее технологическое пространство

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

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

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

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

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

Поэтому когда к вам прибегает заказчик и говорит: «Надо, срочно!», можете ему ответить: «ОК, делай! У меня другие объективно срочные задачи, я уже обещал сделать их, как руководитель команды. К сожалению, ради тебя всё бросить не могу, но если это действительно настолько важно и срочно, можете сделать это сами. Мы со своей стороны поможем, расскажем про нашу инфраструктуру, про продукт, посмотрим все ваши пулл-реквесты, поможем пройти CI/CD».

На самом деле принимать контрибьюты полезно для внутренней разработки. Так растёт ваше capacity, и вы постепенно начинаете превращаться в inner source, а inner source прекрасно масштабируется.

Общее инфраструктурное пространство

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

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

Быть монополистом – вредно

Пользователи не голосуют ни рублем, ни ногами — значит, можно делать что угодно, они никуда не денутся и будут вами пользоваться. Так?

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

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

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

Чек-лист тимлида внутренней разработки

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

Если вы работаете во внутренней разработке, что у вас должно быть:

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

• Я ограничиваю каналы коммуникации о работе. Если вы будете ограничивать каналы коммуникации о работе, у вас не будет разрывов в личной эффективности и выстроится work-life balance.

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

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

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

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

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

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

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

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

27-28 февраля В Москве пройдет юбилейная, десятая конференция TeamLead Conf. Приходите послушать мой доклад «Самый шерстяной волчара: тимлид с технической ролью и без», а также трек Яндекса об RnD и культуре компании.