Переход на тёмную сторону я заметил по вопросу, который стал задавать сам: «А что это даст компании?» Раньше такие вопросы чаще прилетали с другого конца стола. Теперь я сидел там.
Я всё ещё понимал код, мог спорить об архитектуре и прекрасно знал, почему разработчик морщится от слов «небольшая доработка». Только работал уже руководителем направления на стороне заказчика. Нужно было решать, на что тратить время команды, какие системы развивать и какие пока достаточно привести в рабочее состояние.
Фраза «сделали по техническому заданию» перестала подводить итог разговора. За ней неизбежно следовало: сотрудники теперь работают быстрее? Перестали что-то делать руками? Или у нас просто появилась ещё одна функция, которую придётся поддерживать?
Хромая лошадь, на которой ездит компания
Одной из основных систем был Битрикс24. Назвать его CRM было уже трудно: вокруг него жили работа с клиентами, корпоративный портал, задачи, коммуникации и внутренняя автоматизация. Заходишь поправить что-нибудь небольшое, а от этого небольшого зависит чей-то рабочий день.
Состояние системы радовало меньше. Накопились доработки, старые решения, проблемы после обновлений. У некоторых процессов была богатая история и довольно туманное устройство. Когда-то их сделали под конкретную потребность, потом потребность изменилась, а код остался. Трогать его желающих было немного.
Битрикс24 напоминал хромую лошадь. Ехать ещё можно, но медленно, недалеко и желательно без резких движений. Для системы, на которой держится заметная часть компании, так себе характеристика.
Разработчик во мне периодически предлагал всё переделать. Я его понимал. Некоторые куски действительно хотелось разобрать до основания. Но теперь мне самому приходилось отвечать на вопрос: а чем компания будет пользоваться, пока мы строим прекрасное новое?
Продажи не возьмут паузу на переписывание. HR продолжит нанимать людей. Сотрудники утром откроют привычный портал и захотят работать. Мою любовь к хорошей архитектуре они в этот момент разделять не обязаны.
Поэтому задача получилась без особого романтизма: обновить систему, стабилизировать, разобраться с накопленным. Довести лошадь до состояния, в котором на неё можно рассчитывать.
Лучший комплимент — перестали вспоминать
Большого релиза с надписью «теперь всё хорошо» у нас не было. Стабильность собиралась постепенно: обновления, разбор доработок, работа с производительностью, проверка процессов и зависимостей.
Где-то требовалось поправить архитектуру. От какой-то доработки оказалось разумнее отказаться. Иногда полезнее было описать, как всё устроено, чем добавить очередную функцию. А отдельные места мы сознательно оставляли в покое: цена изменения пока превышала пользу.
У этой работы неприятная особенность: её трудно эффектно показать. На демонстрации хочется открыть новый экран, нажать кнопку. А у тебя достижение — очередное изменение прошло без привычного ожидания, что сейчас отвалится что-нибудь по соседству.
Постепенно про Битрикс24 стали меньше говорить. Им продолжали пользоваться, просто он реже становился поводом для отдельного разговора. Вот это я и запомнил как результат. Для внутренней системы спокойствие пользователей оказалось гораздо убедительнее красивого отчёта о проделанной работе.
Сначала выяснить, как у нас принято
Следом мы занялись развитием внутренних процессов. Среди них были «Адаптация персонала» и «Оценка персонала». По названию — обычная автоматизация. Открывай редактор, рисуй формы, раздавай задачи.
На деле программирование приходилось отложить. Допустим, в компанию пришёл человек. HR что-то делает со своей стороны, руководитель — со своей, IT готовит доступы. Самому сотруднику тоже нужно пройти определённые этапы. Кто следит за тем, чтобы всё это произошло, и кто вернётся к новичку через несколько недель?
Пока порядок живёт в головах, каждый немного дописывает его под себя. У одного HR таблица, у другого календарь. Один руководитель помнит про новичка, другому надо напомнить. На вопрос о правиле можно получить вполне искреннее: «Мы обычно делаем вот так».
Системе слово «обычно» объяснить трудно. Ей нужны условия: кто отвечает за этап, когда он начинается, что считается завершением, кому сообщать о задержке. Приходилось разбирать эти вопросы вместе с бизнесом. Иногда именно попытка автоматизации заставляла впервые договориться о том, что до этого все считали и так понятным.
С оценкой персонала история повторилась, только вопросы были другие. Кто оценивает сотрудника и по каким критериям? Кто видит результат? Где остаются договорённости после встречи? Как посмотреть несколько периодов, а не только последнюю оценку? Что делать, когда сотрудник и руководитель очень по-разному видят результат работы?
Можно быстро сделать форму и сохранить ответы в базу. Но от этого ещё не появится работающий процесс оценки. Мне пришлось привыкнуть, что значительная часть моей работы происходит до того, как разработчику вообще есть что отдавать.
Agile и арифметика аутстафа
Примерно тогда же у меня случилось первое серьёзное знакомство с Agile на практике. Термины я знал и раньше. Но пользоваться словами «спринт» и «ретроспектива» оказалось проще, чем добиться понятного ответа на вопрос, где у команды застряла работа.
Меня всё больше интересовала прозрачность: чем заняты люди, почему выбраны именно эти задачи, что мешает закончить и когда бизнес сможет попробовать результат. Если доска помогала это увидеть — хорошо. Если мы просто аккуратно передвигали карточки, легче от этого не становилось.
Работы прибавлялось, и команду начали усиливать через аутстаф. Здесь тоже пришлось пересмотреть ожидания. В воображаемой арифметике всё замечательно: к пяти разработчикам добавили двух, получили почти сорок процентов прироста. В проекте сначала получаешь вопросы, которые нужно кому-то объяснить.
Новому человеку нужны доступы, контекст, знакомство с архитектурой и командой. Особенно полезно рассказать, почему некоторые странные решения выглядят именно так. Иначе он потратит время на исправление того, что кажется ошибкой, а потом выяснит, какое ограничение за этим стояло.
Пришлось внимательнее относиться к документации, правилам работы и code review. То, что маленькая группа решала разговором через стол, в распределённой команде само собой уже не происходило. Добавить людей оказалось возможно. Добавить им общее понимание проекта одной командой — нет.
Собеседование без соревнования в эрудиции
Технические вопросы я задавать не перестал. Нужно понимать, с каким кодом человек справится и где ему понадобится помощь. Но раньше было легко увлечься экзаменом: ООП, индексы, особенности PHP, ещё одна задачка на знание языка.
Теперь мне хотелось узнать, как кандидат ведёт себя в обычном проектном беспорядке. Задача сформулирована плохо — он уточнит или молча реализует своё понимание? Оценка оказалась неверной — когда об этом узнает команда? Если не согласен с замечанием на code review, сможет объяснить свою позицию?
Отдельно интересовало, может ли человек рассказать о технической проблеме тому, кто не занимается разработкой. На стороне заказчика это перестало быть абстрактным пожеланием к «коммуникабельности». Такие разговоры были частью работы.
Редкий вопрос из внутренностей языка сам по себе мало помогал выбрать будущего коллегу. У меня уже было достаточно поводов ценить человека, который задаёт вопросы вовремя, умеет читать чужой код и предупреждает о проблеме до последнего дня.
По обе стороны стола
Шутки про заказчика я после этого понимать не перестал. Внезапные требования, сроки «вчера» и правки «на пять минут» никуда не делись. Просто за некоторыми из них я теперь видел то, чего раньше не замечал: обязательства перед другими подразделениями, бюджет, зависимость от соседнего проекта, изменение внутри компании.
Это не делало любой запрос разумным. Зато помогало сначала выяснить, откуда он взялся. С бизнесом нужно было обсуждать результат и процесс, с разработчиками — ограничения, архитектуру и срок, в который действительно можно уложиться. А потом добиваться, чтобы обе стороны договорились об одной и той же работе.
В предыдущем этапе я учился руководить направлением со стороны исполнителя. Здесь пришлось отвечать ещё и за то, какую работу вообще стоит начинать.
Самое странное ощущение было в том, что я заранее знал обе реплики. Мог произнести «почему так долго?» — и тут же подробно ответить самому себе. Тёмная сторона оказалась местом, где спор с заказчиком иногда приходится целиком проводить у себя в голове.
