Очень частая проблема IT проектов заключается в том, что программисты делают много работы, а менеджеры / руководители ее не видят.
Копнув вглубь проблемы, окажется, что подобная ситуация сложилась по вине обеих сторон:
Если вы — руководитель, то отсутствие результата всегда ваша ошибка.
Если вы программист, который «не показывает результат», значит вы недостаточно компетентный программист.
Мы часто забываем, что «компетентность программиста» заключается и в soft skills, например умение «продавать / демонстрировать свою работу».
Подобные ситуации часто приводят к недопониманию и накалу отношений в проекте, что явно плохо сказывается на самочувствии и результативности команды.
Кто-то скажет: «Ты не прав! Я программист и не должен продавать свою работу!» — ну и сдохни, съеденный рынком. Успех профессиональной деятельности состоит из множества факторов и однобокость очень ограничивает потолок роста.
Что делать?
Поделюсь одним из множества подходов, которым я научился за годы в IT. Он подходит не под все ситуации, но попробовать его стоит. Он часто вызывает судороги и агрессию у программистов, но из-за неопытности. Я сам долго его любил этот подход, пока не научился с ним работать («и жизнь стала лучше»)
Договориться об универсальной системе измерения результата
Все просто: заранее между руководителями и IT штатом должна быть договоренность о метрике результата, который будет понятен обеим сторонам.
Одной из самых простых и понятных единиц измеренния результата меня научил Олег Козырев (сооснователь Рокетбанка).
«Все что не в Production, не считается выполненным»
Вот и все, настолько просто: если вы не можете потыкать это в production (в боевом доступе), значит эта задача еще не выполнена.
Для руководителя это очень простая мерка, ему достаточно посмотреть что он может на боевом сайте воспользоваться функционалом и получить нужный результат.
Засчет этого, например, Олег способен был управлять сразу множеством проектов, потому что у него был очень просто показатель выполненной работы.
Программисты не очень любят эту мерку, потому что «сделать задачу» гораздо проще, чем «сделать задачу и вынести на production». Обычно второй вариант занимает на x2-3 времени больше.
Процесс «сделать задачу» превращается в «сделать -> собрать -> стейджинг -> правки -> тесты -> production -> тесты -> правки -> повторить 1-2 цикла».
А бизнес не любит ждать так долго. И если в руководстве нет понимающего технологический процесс человека, то невозможно объяснить почему «задачу на час», программист оценивает в «задачу на день», а Team Lead понимает, что это «задача на 3 дня».
Тут вашей команде остается молиться, что в руководящих позициях есть хотя бы 1 грамотный CTO или консультант, который и программистов пнет, поправив в своих вычислениях, и с руководством поругается, отстаяв сроки.
Есть пару «НО»
Должно соблюдаться несколько условий обеими сторонами:
- Должна быть мини-презентация результата. Вы должны показать его, дать комментарии, описать что именно было обнаружено или изменено в процессе реализации задачи, какие проблемы обнаружены и как на них больше не натыкаться.
- Поставьте табу на накидывание новых задач, пока вы не отдали его на тест клиентам. Об этом обязательно будет отдельная статья.
- Срок исполнения должны ставить исполнители. Компетентный вы или нет в области программирования, никогда не пытайтесь решить сколько времени займет та или иная задача у программиста, И ДАЖЕ если вы способны оценить время, сначала спросите, а потом, во время обсуждения, попытайтесь его поправить.
- Чтобы верить сроку исполнения у вас должно быть доверенное лицо, такое как CTO или консалтер, которое может подтвердить реальность поставленного срока.
Если вы по-прежнему не можете построить нормальный процесс получения результата, значит пришло время пригласить специалиста.
Являетесь ли вы СТО, работаете со студией или подрядчиком, в-любом случае, у вас уже есть проблема и нужен взгляд со стороны, чтобы оценить ситуацию и найти способ, как все поправить. Пишите, я с большим удовольствием Вам помогу.
