«Не допускайте прозрачности в компании». Продолжение очень вредных советов от CTO «самого горячего» белорусского финтех-стартапа, ч. 2

21 комментарий
«Не допускайте прозрачности в компании». Продолжение очень вредных советов от CTO «самого горячего» белорусского финтех-стартапа, ч. 2

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

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

Revolut заставляет сотрудников увольняться по собственному
Revolut заставляет сотрудников увольняться по собственному

Revolut заставляет сотрудников увольняться по собственному

Резидент ПВТ купил хорватскую игровую студию
Резидент ПВТ купил хорватскую игровую студию

Резидент ПВТ купил хорватскую игровую студию

Qulix Systems и А1 внедрили IoT-решение для контроля безопасности мостов
Qulix Systems и А1 внедрили IoT-решение для контроля безопасности мостов

Qulix Systems и А1 внедрили IoT-решение для контроля безопасности мостов

Подразделение Mail.ru отдаст разработчикам игр 90% от дохода
Подразделение Mail.ru отдаст разработчикам игр 90% от дохода

Подразделение Mail.ru отдаст разработчикам игр 90% от дохода

Обсуждение

Anonymous
Anonymous
5

"Для среднесрочного и долгосрочного плана наиболее важным элементом является KPI — показатели, которые тебе помогают понять, ты достиг результата или нет, даже в случае выполнения всех задач. Например, у тебя был план повысить эффективность отдела разработки. До всех изменений ты зафиксировал, что один разработчик может выполнять 90h задач в месяц, остальное время уходит на другие активности. Затем ты ввел изменение в процессе, и разработчик стал выполнять 70h задач в месяц. Очевидно, что-то пошло не так."
-------
Ох уж эти эффективные менеджеры, любящие KPI и любящие увеличивать утилизацию члоевеческих ресурсов. Вы ж таким образом просто накапливаете технический долг. С введением какой-то метрики всгда идут последствия, а с четкими KPI для программистов, начинаются оптимизации этого KPI и следовательно важные вещи которые нельзя выразить в метриках и которые требуют твореческих и непрогнозируемых усилий, такие как тех долг, архитектура, расширяемость, читаемость кода, эксперменты и прототипы итд...., все это начинает выпадать из процесса. И сама атмсфера разработки превращается в конвеер и заинтересованость сотрудников в резултате пропадает, только в увеличении странных метрик.

1

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

Dmitry Gorokh
Dmitry Gorokh Director of Strategic Communications в ID Finance
0

Пока нормальный результат: 600+ сотрудников, 8 стран, выручка $141.3m за 9 мес.2018, рейтнги FT1000 https://goo.gl/7xQ457 и Inc5000 https://goo.gl/Ns6AJL

Anonymous
Anonymous
2

"У визуальной связи психологический эффект: ты не просто переписываешься с каким-то ноунеймом, а работаешь с реальным человеком! И если коллега не звонит тебе по видеочату, появляется ощущение, что он не очень серьёзно относится к вашей общей задаче."
-------------------------------------------------
А мне вот нравиться противоположная точка зрения у Егора Бугаенко. Хоть в некоторых аспектах взгляды Егора очень спорны.
https://www.yegor256.com/2015/07/13/meetings-are-legalized-robbery.html

Anonymous
Anonymous
2

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

Dmitry Gorokh
Dmitry Gorokh Director of Strategic Communications в ID Finance
0

В примере в тексте баг на стороне компании, тут уж никаких других вариантов нет, только идти на уступки пользователю. Но в целом вы правы. Генри Форд говорил что-то вроде, "если бы я спросил клиентов, чего они хотят, то ответ был бы - более быстрых лошадей"!

Anonymous
Anonymous
0

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

0

Кто-то еще ведется на такую низкопробную джинсу?

0

Не совсем низкопробная. Букаф то много написал. Больше, чем обычно пишут. :)

0

был пару лет на собеседонваии . тех часть прошел далее прихожу к автору этой статьи. все круто но на испыталку мы будем платить тебе минус 200$ вопрос почему а зачем да просто так
естесвенно на работу к ним я не вышел)

Юлия Голуб
Юлия Голуб HRM в ID Finance
1

Ситуация с вами была я так понимаю давно, с тех пор много воды утекло, будем рады пообщаться снова и расставить все точки над i :)

2

Статьи данной серии будут выходить пока фотки в личном архиве автора не кончатся.
Что-нить в стиле unicorn dick up ерлиха было бы кстати http://s3.amazonaws.com/assets.piedpiper.pro/app/uploads/2016/06/piedpiper_308_blog_03.jpg

Александра Година
Александра Година Communications Manager в Apalon
2
-2

да камон, народ. снимите розовые очки. это пишется не для вас. а для будущего работодателя

Александра Година
Александра Година Communications Manager в Apalon
0

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

1

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

Александра Година
Александра Година Communications Manager в Apalon
0

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

0

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

С клиентом - всегда отправлять фоллоуап. С коллегой - всегда добавлять пометки. Лучше прямо во время разговора на расшареном экране. Оба учавствуем, один пишет.

1

Видеозвонки это тоже ОК. Постепенно становится стандартом, ИМО.

1

И если коллега не звонит тебе по видеочату, появляется ощущение, что он не очень серьёзно относится к вашей общей задаче.

Тоже юзаем видео чат, это правда так работает. В целом статья годная. Автору UP.

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже