Трое против пятнадцати
Однажды ко мне обратился руководитель одной онлайн-школы за консультацией. Их отдел разработки из 15 человек работал очень медленно...
Как-то ко мне обратился руководитель одной онлайн-школы (специально не указываю названия). Школа с большим годовым оборотом, название на слуху. Серьезный отдел разработки, состоящий из 15 человек - программисты, тестировщики, проджект-менеджер...
Руководитель попросил у меня консультацию. Его беспокоило, что в таком большом отделе задачи двигаются медленно. Новые задачи воспринимаются программистами в штыки и саботируются. Особенно когда нужно переделывать что-то. Отдел обходится в круглую сумму. И руководителю хотелось понять, что не так и что можно сделать.
Поясню. У нас в школе похожий объём задач. А отдел разработки состоит из 3 человек, включая меня.
Мы созвонились. Я выслушал, как у них всё работает, как происходят процессы. И попробовал рассуждать, что может быть не так и как это теоретически можно исправить.
Я не давал советов, не говорил, как правильно. Я только высказал своё мнение и рассказал, как это устроено у нас.
Глазами сотрудников
В своей карьере я был во всех ролях - от мелкого подчинённого до ИП и до руководителя отдела в крупной компании. Я примерно понимаю, как себя ощущают и что хотят люди на всех этих уровнях.
Возьмем какую-нибудь задачу и рассмотрим её с точки зрения разных сотрудников.
Директор хочет протестировать новую функцию. Он даёт задание руководителю разработки. Тот отдаёт проджект-менеджеру, который расписывает ТЗ для программистов.
Что важно директору? Чтобы быстрее появилась новая функция, чтобы проверить, есть ли от неё прок, продвинуло ли это компанию вперёд.
А что с точки зрения простого программиста? Ему приносят задачу переделать функционал, который он делал на прошлой неделе. Т.е. он что-то делал, а сейчас это заставляют сломать и сделать заново, но чуть иначе. В этот момент появляется протест и саботаж.
Поэтому в команде очень важно доносить не просто, ЧТО нужно сделать, а ДЛЯ ЧЕГО мы это делаем.
Где можно споткнуться
А ещё встречаются такие штуки, как отсутствие приоритетов - когда вместо функционала, который важен сейчас, делается что-то совершенно неважное. Размытие ответственности - когда никто не знает, кто за что отвечает. Или, например, в команде два «фронта» и два «бэка». Приходит задача для «фронта». Кто из двоих возьмёт её? Особенно если идёт саботаж задач. А потом они будут друг на друга кивать, что «думали, что он возьмёт». Не просто так же есть известная шутка/мем: «Что один программист сделает за месяц, два программиста сделают за два месяца».
Особенности моей команды
В моей команде мы придерживаемся строгой приоритизации - в работе в данный момент те задачи, которые нужны бизнесу в данный момент. Если задача срочная, мы переключаемся на неё. Остальное - потом. А если что-то нужно переделывать, все члены команды знают, для чего это делается. Да, у нас тоже есть недостатки. Иногда мы можем выложить в прод сырой функционал, который вызывает ошибки или глюки. И в данном случае тестировщиком выступает наш клиент. В этом случае мы готовы оперативно исправить возникающие ошибки. Но с точки зрения бизнеса это оправдано, т.к. бизнесу важен не красивый и чистый код, а результат, и чем быстрее, тем лучше.
Итог
И да, с человеческой стороны меня «погрело», что мой отдел из 3 человек оказался эффективнее, чем отдел из 15 человек на похожем объёме задач.
Я не претендую на истину, т.к. делюсь только своим опытом. Но на созвоне директор этой школы вынес для себя несколько полезных инсайтов. И я надеюсь, что мне удалось помочь им.
Если вы хотите обсудить какую-то задачу или просто посоветоваться, свяжитесь со мной. Буду рад помочь.