--- title: Извлекая полезный опыт IT-компаний date: 2017-11-06T10:00 tags: [управление] --- Я работал уже больше 12 лет в разных IT-компаниях и захотел в порыве ностальгии выписать разницу между ними, лучшие стороны, что-бы вы тоже могли научиться у них. Поехали.. ### Внутренняя прозрачность улучшает культуру и здоровье компании Практика периодической **финансовой отчётности** начальства перед своими работниками сильно успокаивает. Это происходит в форме докладов «мы выиграли проект на X тысяч евро», «мы пробуем такой-то гос-тендер» или «вот как наша цель по прибыли соответсвует действительности», «у нас наличных на X лет выплаты зарплат», «мы прибыльны». Врядли кто-то доходит до радикальной прозрачности где все знают какая у кого зарплата. В более общем виде, внутренняя прозрачность компании проявляется в том что **каждый работник знает то что его не касается напрямую** - какие проекты выпустились какой-то коммандой (demo meeting), какие ошибки и инциденты возникают в продуктах (доступный всем error log), что хотят клиенты (feedback), какие бизнес-метрики у проектов (analytics).  В обычных компаниях доступ к гугл-аналитике есть только у избранных, вы как работник можете только догадываться о финансовом положении компании, с реальными клиентами разработчики не общаются, а NDA ограничивает внутреннее общение между командами. > При этом каждый продукт (В Apple) имеет свой NDA, поэтому ты часто не знаешь, над чем работает твой сосед, и вы ничего не можете обсудить > > [Ирина Березань, разработчик](https://vc.ru/26084-ukrainian-dev-in-usa) ### Управление проектом это воронка Управление проектом это сложный процесс и в хороших компаниях он настроен оптимально. Это проявляется в **еженедельных совещаниях** по разгребанию планов, которые разбиваются на иерархию и превращаются в документацию и оценку по времени. Чем детальней разбивается задача, тем больше людей должны её обсуждать и тем точней будет оценка. Процесс постепенный и цикличный (поэтому _воронка_). Если коротко, то: 1. PM продумывает и создаёт **Features**. Фича может затрагивать разных действующих лиц и разные сценарии использования. 2. PM + grooming team создают **User Stories**. Это сценарии использования конкретных лиц 3. TL создаёт **Tasks**. Это технические задачи по измнению конкретного сервиса. Связываются друг с другом и со сценарием Непонятные задачи нуждаются в _изучении_ которое _ограничено по времени_. **Пожелания по** улучшениям и рефакторингу выписываются в отдельный список (**parking lot**), который можно сделать отдельным спринтом. В обычных компаниях, нет постоянства в митингах, ритм рванный - то аврал, то кодинг с запоем. Требования остаются слишком абстрактными и разработчик как творец, сам решает как он их понимает, что-бы потом переделать. Поскольку требования не записываются, теряются причины решений.  ### Традиции и игры сближают коллектив Офисная работа не пыльная, но сильно может давить на психику. Что-бы отвлечься некоторые компании стимулируют отдых за настольным футболом, mortal combat или fifa в PS4, а в особых случаях и коллективным турниром в LoL, Dota или Red Alert 2. В некоторых компаниях, принято что работники угощают коллектив собственными кулинарными произведениями на праздники. В обычных компаниях быту не уделяют столько внимания ### Команда многофункциональна и специализирована В обычных компаниях каждый член комманды (макс 10 чел) имеет чёткую специализацию - дизайнер, frontend, backend и тд. Это даёт хорошую эффективность при равномерной нагрузке. Но такая команда ограничена пропускной способностью самого слабого звена (скажем мануальным тестером или дизайнером). В хороших компаниях **каждый** член команды **умеет** рисовать, верстать, проектировать API и БД, деплоить и тестировать (т.е. он кроссфункционален). Он не так хорош как тот специалист с 10-летним стажем, но при этом играет конкретную **роль** (я например - в основном backend и архитектура). Болезни или отпуска мало влияют на эффективность комманды, т.к. она **масштабируется линейно** независимо от типа задачи. ### Асинхронные процессы Асинхронность значит что теперь все  ****всё записывают****  и не  ****прерывают работу****  друг друга. Всё работает как в nodejs на основе событий или callback-ов.  - Общение проходит в основном через групповой чат (по которому можно искать) - Каждый митинг имеет письменный результат работы (meeting notes), последствия для участников (action points) и  ****live видео-трансляцию с видео-записью**** - Результат работы проходит фазу review. Тексты для user-stories и документации можно inline-комментировать в Confluence. Вёрстку дизайна в Zeplin/Sketch тоже можно ревьюить. - Самое главное, все изменения кода и конфигурации инфраструктуры в проекте проходят через  ****коммандный pull-request review**** .  Всё это делается для тех работников, кто не может  ****присутствовать в этом же пространстве-времени**** , для  ****долговременной памяти компании**** ,  ****масштабируемости организации****  и наконец для глобального поиска. В обычных компаниях  - митинги никто не записывает - все друг друга прерывают - разработчики прерывает PM/дизайнера что-бы понять что именно надо, QA что-бы объяснить как что тестировать, Opsов - как деплоить готовую работу из-за особенностей конфигурации. И наоборот, PM/ops может прерывать разработчиков из-за багов или из-за горящих сроков - ревью кода не проходит через всю комманду - достаточно подтверждения кода от TL и функциональности от QA ### Быстрый автоматический деплоймент В хороших компаниях деплоймент происходит как только микро-задача готова - каждый день или каждую неделю, а не пачкой раз в пол года. Это решается дублированием и скрытием новой функциональности (т.н. feature-toggling) которая ко всему прочему позволяет накатывать изменения части клиентов и проводить A/B тестирование.  Во-вторых, **деплоймент автоматизирован** настолько, что при подтверждении pull-request'а, изменения сами попадают на production, а не ждут ручного деплоймента. Это требует не только хорошего конвейера непрерывной сборки проекта с автоматическим тестированием, но и хорошего мониторинга ошибок и возможности отката изменения (контейнеризация) ### Быстро меняющиеся проекты расширяют кругозор Это возможно пожалуй только в маленькой студии. Если вам не нравится пилить CMSку, то через 3 месяца вы уже познакомитесь с CRMкой, ещё через 4 — с ITIL, SMS-gateway или индексацией. Быстро меняющиеся проекты позволяют и быстро менять технологии, пробовать новые фреймворки. Минимум бюрократии, максимум эффективности. ### Внимание к рабочему месту влияет на качество кода В хороших компаниях серьёзно относятся к рабочему месту. Разработчикам дают лаптопы (макбуки), хорошие монитор(ы), хорошие стулья и регулирующиеся по высоте столы. Эти инвестиции поднимают работнику самоуважение, не дающей писать говнокод по «теории разбитых окон». Лаптопы лучше стационарных т.к. их можно брать на совещания и работать из дома. Пространство офиса организуется по принципу группировки в команды так что-бы минимизировать уровень фонового шума и максимизировать общение этой группы. В обычных компаниях open space, разношёрстная мебель и железо, которое ещё надо выбивать Если вы как разработчик чувствуете что вам этого не хватает, то у нас в Pipedrive все эти пункты отличные. И мы [нанимаем](https://www.pipedrive.com/en/jobs) кадры ## Related - [Estonian Mafia](/ru/blog/философия/estonian-mafia/) - [OpenUP](/ru/blog/философия/openup/) - [Rapid application development](/ru/blog/философия/rapid-application-development/)