CTO ID Finance Павел Шарейко продолжает перечислять проступки, грехи, преступления и косяки, которых должна избегать правильная компания. О чётких точках коммуникации, дедлайнах в рукаве, психологической пользе видеочатов, о чем следует помалкивать в аутсорс-компаниях, каков QA хорош, и как хитростью вовлечь сотрудника в неизбежное участие в конференции.
Первая часть Вредных советов — тут.
13. Практикуй хаотические коммуникации
Представьте ситуацию: начинается очередная итерация разработки. Все задачи должны «упасть» бизнес-аналитику, тот должен обсудить их с бизнес-подразделениями, руководителями, стейкхолдерами проектов, проработать и отправить на оценки лидам. Каждый лид распределяет их на разработчиков, учитывая их знание домена. Задачи оценивают, согласовывают конечный вариант — и, наконец, запускается разработка.
Выглядит несложно. На практике по-другому. Сотрудники из лучших побуждений пренебрегают процессом и пытаются получить результат по своей задаче быстрее.
Например, бизнес-аналитик приходит напрямую к разработчику и просит его «очень срочно» оценить задачу. Как итог, лид выпадает из контекста: он ожидал, что разработчик закроет за день три важных бага, а тот сидел и оценивал задачу для бизнес-аналитика. Итог прогнозируемый — незакрытые дефекты смещают поставку обновлений на production-сервер.
Чем больше в компании общения — тем лучше. Но внутри глобальных бизнес-процессов — планирование спринта, доставка релиза, разбор сложных проблем, — должны быть установлены чёткие точки коммуникации. И весь основной поток информации должен проходить строго через них. Выбрасывать из этой коммуникационной цепи отдельные звенья — разрушительная практика. В тоже время, например, если разработчику пришла задача от конкретного риск-аналитика, и по этой задаче есть вопросы, можно просто пойти и обсудить их с этим риск-аналитиком, не нужно играть в футбол и переводить задачу на доработку с комментарием «Требуется доработка. У нас процесс».
14. Не согласовывай приоритеты с отделами
Расскажу историю о том, как мы создавали отдел безопасности. К нам пришли опытные, технически подкованные люди, и они с порога начали заниматься управлением доступа: например, решать, как и у кого нужно запрашивать пароли к базе данных. А для компании критичной была безопасность приложения: ведь если продукт взламывают, мы несём прямые убытки. Access management тоже важен, но чтобы привести его в порядок, нужен год. А разобраться с основными проблемами безопасности приложения можно за несколько месяцев.
Безопасники выкладывались, зачастую даже засиживались на работе, но с точки зрения менеджмента они откладывали более важные проблемы на потом. Накапливалось недопонимание, обиды: «Мою работу не ценят, я ухожу». Чтобы такого не происходило, руководству нужно быть на одной волне с отделами, понимать, куда они двигаются стратегически и выгодно ли это компании.
Для этого мы с каждым отделом согласовываем долгосрочные и краткосрочные планы. Долгие — что мы планируем сделать за полгода-год, хотя бы приблизительно. Короткие — это четыре-пять двухнедельных спринтов, поскольку мы работаем по scrum. При этом, конечно, в таких планах не обязательно жёстко специфицировать каждую задачу: задача детализируется перед стартом спринта и как правило требует предварительного анализа.
15. Не рассказывай людям о глобальных дедлайнах компании, не проверяй частичный результат
Людям надо рассказывать всё. Доводить основные цели компании, глобальные дедлайны по проектам, даже если эти дедлайны слишком оптимистичны и потому сложно выполнимы. Даже о плохих, демотивирующих вещах рассказывать тоже нужно, как минимум в продуктовой компании. В аутсорсных, возможно, иногда лучше умолчать: если людям доводить, что они работают на убыточных проектах и они обречены, ничего хорошего это не принесёт.
Если что-то недоговаривать, в компании будет накапливаться непонимание между людьми. А чем больше непонимания, тем больше проблем в процессах.
Пример. Заказчик говорит тимлиду, что новый функционал нужно сделать ровно за месяц. Лид, уверенный в своей команде, обещает заказчику, что всё успеет. А команде об этом — ни слова.
Разработчики трудятся в привычном режиме и отдают в последнюю неделю результат на тест. Уже с небольшим отставанием. Наконец, QA/BA оценивает результат: оказывается, что нужно часть логики переделать. Сроки поджимают, лид начинает подгонять команду. Итоги: костыли в коде, аврал, переработки, отставание с доставкой функционала.
Тут две проблемы. Во-первых, команда не знает дедлайнов — значит, не чувствует ответственности. Во-вторых, реализация задачи спланирована единым куском. Для подобных интеграций нужно закладывать риски по времени и разбивать задачу на части, то есть команде лучше довести более реалистичную дату. Разработчик получает нужное время на стабилизацию, а ты — уверенность в том, что успеешь вовремя.
16. Никогда не используй видеочаты
Мы общаемся в почте, скайпе, чатах. Но видеочат работает лучше всего, особенно когда команда распределённая. Вначале это казалось нам всем немного диким: тебя будто на камеру снимают, все хихикают, посмеиваются. Но теперь мы используем видеозвонки даже для решения мелких вопросов.
У визуальной связи психологический эффект: ты не просто переписываешься с каким-то ноунеймом, а работаешь с реальным человеком! И если коллега не звонит тебе по видеочату, появляется ощущение, что он не очень серьёзно относится к вашей общей задаче.
17. Масштабируй компанию, не обращая внимания на бизнес-результаты
Некоторые заказчики спрашивали у меня: «Слушай, вот у вас сейчас проблемы с производительностью, вы говорите, что для их решения нужно время. Скажи, почему вы сразу не сделали всё хорошо?». Конечно, мы могли сразу «сделать хорошо», вот только это стоило бы нам в два-пять раза дороже. Поэтому мы решили сделать в два раза дешевле, посмотреть, можно ли на этом зарабатывать деньги, а уже потом стали тратить деньги на масштабирование.
Я считаю, что наша компания эволюционировала правильно. На старте, в 2012 году, мы набрали только Java-разработчиков — без фронтенда, без разработчиков под Android, без QA и без BA. Проект ещё не стартанул, мы не были уверены, что он принесёт прибыль, поэтому и решили ограничиться джавистами. И технологии выбрали под них: JSF, GlassFish application server, база данных MySQL, Hibernate.
Конечно, со временем мы поняли, что бэкенд-разработчики плохо делают фронтенд: это занимает у них много времени, а результат визуально выглядит как старое банковское ПО, сделанное на Delphi, что для веба абсолютно неприемлемо. Поэтому мы пошли дальше: отказались от JSF, сделали REST API, наняли команду фронтенда. Возникла необходимость увеличивать привлечение клиентов — наняли команду Android и пришли на мобильный рынок.
Но всё это мы делали только тогда, когда бизнес-результаты компании это позволяли. Думать о масштабировании надо, если это соизмеримо с текущим состоянием проекта. Разумеется, если надо просто заложить какие-то архитектурные моменты на самом старте цикла разработки, и это не стоит кучу денег, то об этом стоит подумать сразу. Но если это требует дополнительных ресурсов — в два, три, четыре раза больше, чем есть — с масштабированием стоит повременить.
18. Не допускай прозрачности в компании
Никогда в жизни прозрачность ещё не сыграла со мной злую шутку. Чем прозрачней деятельность компании, тем меньше проблем: с инвесторами, с бизнесом, с внезапными увольнениями. В идеале все отчётности должны строиться максимально быстро и просто, но чем больше в них прозрачности, тем проще тебе работать, особенно в продуктовой компании. Когда в «закрытой» компании меняется топ-менеджмент, и новый человек видит, что вся отчётность под грифом «секретно», у него возникает ощущение обманутости.
Ещё одна вредная привычка — не слушать или не слышать сотрудников. Услышан должен быть любой сотрудник независимо от позиции — не так важно, своим прямым руководителем или топ-менеджером. Хорошая компания должна строиться на том, чтобы каждый человек мог поделиться идеей, выговориться, и был уверен, что его выслушают. Если этого нет, накапливаются недоговорённости, люди выгорают, начинают ходить по собеседованиям, и в конце концов уходят. И, как правило, от плохих процессов или из плохих коллективов первыми уходят лучшие.
19. Не слушай клиентов, пусть жалуются
Для нашей компании плохое отношение клиентов к продукту — это прямые убытки и репутационные риски. Будут негативные отзывы в веб-пространстве — пользователи перестанут брать кредиты, мы — привлекать депозиты. Инвесторы тоже не станут приходить в компанию со спорной репутацией.
У нас есть несколько уровней поддержки, чтобы оперативно закрывать любые проблемы пользователей. И для нас клиент всегда прав, даже если из-за этого мы теряем деньги. Например, если по оферте мы должны начислить пользователю долг, но из-за бага в его личном кабинете этот долг не отобразился, мы погасим эту задолженность бонусами — клиента не обидим.
20. Индустриальные конференции не нужны, не ходи туда, не заводи знакомства
Выступать на конференциях полезно. Во-первых, пока готовишься, актуализируешь знания в голове. Во-вторых, слышишь новые мнения, видишь опыт других людей. В-третьих, развиваешь ораторские и коммуникационные навыки. Ходить на конференции слушателем — тоже хорошо. Конечно, для расширения кругозора достаточно смотреть видеозапись события. Но если ты хочешь завести полезные контакты, порасспрашивать коллег, поучаствовать в сообществе, то конференции, форумы, митапы — один из лучших способов.
Что делать, если люди отказываются от выступлений, ссылаясь на занятость? Предлагайте им участие за полгода до конференции. На событие, которое произойдёт не скоро, психологически согласиться проще. А когда до даты останется месяц, и настанет время назвать тему выступления, согласившемуся уже некуда деваться: он же пообещал!
Готовиться к выступлению в последние недели перед конференцией, по-моему, нормально. Как правило, на конференциях ты рассказываешь о практических вещах, с которыми работаешь каждый день — то есть основная подготовка проходит в фоновом режиме. Остальное время нужно, чтобы актуализировать знания.
21. Развивайся только в своей специальности, расфокус вреден
В больших компаниях встречается вредная тенденция: разработчики отдают QA абсолютно непроверенный функционал. Мотивируют так: «Мы же разработчики, почему мы должны делать работу за QA?». Это весьма распространенный вредный шаблон.
Но и с QA не всё просто. Не все хотят изучать техническую часть. Бывают даже такие, которые тестируют веб-продукты, не зная, что такое cookie, веб-сокеты. Вообще, хороший QA должен быть немножко девелопером, а хороший дев — немножко QA.
И к другим профессиям это тоже относится. Взаимодействие между отделами всегда происходит на стыке доменов. Например, бизнес-аналитик тоже должен быть немного технарём. У нас в компании есть два вида спецификаций: BRS, то есть business requirement specification, и SRS — system requirement specification. Вторая — это строгий технический документ, который должен быть написан с пониманием алгоритмов, с указанием точек внедрения нового кода. Но отыскать бизнес-аналитика с техническим стеком — достаточно трудная задача, такие люди — ценная находка для компании.
Если ты работаешь в ИТ, ты должен хотя бы чуть-чуть разбираться в каждом домене. Расти вертикально — это хорошо, но ты должен видеть и горизонт, хотя бы концептуально понимать, как работают люди вокруг тебя. Посмотри конференции, почитай best practices других специальностей — обычно этого вполне достаточно. Это позволит тебе и более эффективно делать свою работу, и понимать, о чём говорят тебе коллеги. Для слаженной команды это важно.
22. Ничего не планируй
Не ставить планы — вредная практика. При этом полезными могут быть любые планы: хоть на день, хоть на месяц, хоть на год. Наличие плана дает тебе возможность проанализировать результат, разобрать что пошло не так или что дало наиболее положительный эффект. Когда у тебя есть чёткий план, ты чаще чувствуешь, что всё делаешь правильно.
Для среднесрочного и долгосрочного плана наиболее важным элементом является KPI — показатели, которые тебе помогают понять, ты достиг результата или нет, даже в случае выполнения всех задач. Например, у тебя был план повысить эффективность отдела разработки. До всех изменений ты зафиксировал, что один разработчик может выполнять 90h задач в месяц, остальное время уходит на другие активности. Затем ты ввел изменение в процессе, и разработчик стал выполнять 70h задач в месяц. Очевидно, что-то пошло не так.
Иметь краткосрочные или персональные планы — это для меня «самомотивирующий» элемент. Удалось выполнить все задачи на день, несмотря на срочные проблемы и незапланированные встречи, — уходишь с работы с радостным ощущением. Нет плана — нет ни последовательности в работе, ни чувства удовлетворения от выполнения всех задач.
Работа в id finance
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.