Я работал уже больше 12 лет в разных IT-компаниях и захотел в порыве ностальгии выписать разницу между ними, лучшие стороны, что-бы вы тоже могли научиться у них. Поехали..
Внутренняя прозрачность улучшает культуру и здоровье компании
Практика периодической финансовой отчётности начальства перед своими работниками сильно успокаивает. Это происходит в форме докладов «мы выиграли проект на X тысяч евро», «мы пробуем такой-то гос-тендер» или «вот как наша цель по прибыли соответсвует действительности», «у нас наличных на X лет выплаты зарплат», «мы прибыльны». Врядли кто-то доходит до радикальной прозрачности где все знают какая у кого зарплата.
В более общем виде, внутренняя прозрачность компании проявляется в том что каждый работник знает то что его не касается напрямую — какие проекты выпустились какой-то коммандой (demo meeting), какие ошибки и инциденты возникают в продуктах (доступный всем error log), что хотят клиенты (feedback), какие бизнес-метрики у проектов (analytics).
В обычных компаниях доступ к гугл-аналитике есть только у избранных, вы как работник можете только догадываться о финансовом положении компании, с реальными клиентами разработчики не общаются, а NDA ограничивает внутреннее общение между командами.
При этом каждый продукт (В Apple) имеет свой NDA, поэтому ты часто не знаешь, над чем работает твой сосед, и вы ничего не можете обсудить
Управление проектом это воронка
Управление проектом это сложный процесс и в хороших компаниях он настроен оптимально. Это проявляется в еженедельных совещаниях по разгребанию планов, которые разбиваются на иерархию и превращаются в документацию и оценку по времени. Чем детальней разбивается задача, тем больше людей должны её обсуждать и тем точней будет оценка. Процесс постепенный и цикличный (поэтому воронка).
Если коротко, то:
- PM продумывает и создаёт Features. Фича может затрагивать разных действующих лиц и разные сценарии использования.
- PM + grooming team создают User Stories. Это сценарии использования конкретных лиц
- 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 все эти пункты отличные. И мы нанимаем кадры