Skip to content

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

License

Notifications You must be signed in to change notification settings

trukhinyuri/-DreamDevTeamPrinciples

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 

Repository files navigation

#Dev Team Principles

Created by YURIY TRUKHIN 11.2013 Edition: v.4.1.2

<Прошлый контент был выпилен, как демотивирующая бюрократическая ерунда>

Мы - команда, которая делает компанию номером 1, не похожая на других. Быть другими позволяет нам делать то, что многие не делают, а некоторые считают невозможным. Мы не определяем, где дно в правилах и нормах поведения после которых вас уволят ((c) Elon Musk). Наша команда определяет невероятно высокие стандарты и нанимает исключительных личностей, которым нравится работать каждый день на пределе своих возможностей. Мы не бросаем задачи, пока не сделаем их до конца, сколько сложными они не были бы - так мы растем. Мы хотим окружать себя людьми, которые драйвят правильные вещи, действуют добросовестно, даже если за ними никто не смотрит.

Знания и инициативы, как сделать лучше - приоритет. Еще лучше, если инициативы не только предложить, но и воплотить.

Горизонтальная команда

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

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

Лучше договариваться горизонтально ((c) Алексей Гадалин, sr. manager AWS EC2), т.к. арбитр может выслушав вас принять решение, которое вам не понравится ((c) Ян Лещинский, основатель Яндекс.Облака, VP AWS). 

Обсуждайте потенциально спорные вопросы не в ЛС, а в чатах вашей команды - так коллеги смогут автоматически стать арбитрами и помочь с решением вопроса.

Консенсус позволяет нам вместе быть умнее любого самого умного сотрудника нашего конкурента, и не ошибиться там, где ошибется он.

Leaf–spine структура команды

Мы не размываем ответственность в рамках #DEVteam.

Кто такой техлид?

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

Кто такой оунер?

Человек, которого повесят если проект зафейлится. Часто его называют тимлид или TPO. Он отвечает за весь продукт целиком, процессы в команде, формирование беклога и выступает агентом команды при внешних коммуникациях (в том числе с Business Product Manager, если такая роль существует).

Кто такой директор по разработке?

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

Кто самый главный?

Все разработчики, DevOps/SRE (которые разработчики инфраструктуры) и инженеры, которые делают дело. Главнее них только наши пользователи, которые и платят нам зарплату на самом деле.

Какие самые важные цели?

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

Про должности

Забейте на них. Они вообще не отражают реальности и никогда не будут успевать за изменениями.

Токсичность - зло!

Любой джун или техлид может вам сказать, что вы делаете дичь, и нужно аргументировать свою позицию. Нужно это делать в публичных чатах средства коммуникации. Хорошие идеи могут рождаться у людей любой должности и квалификации и они не менее важны, если приведут нас к успеху. Мы при общении не используем ВЫ, отчество и другие регалии, нам не важен пол, возраст, заслуги, образование и др. о человеке. Важно мнение каждого и уважительное отношение друг к другу по-дефолту, но если аргументированно мы написали плохой код - правим, все мы пишем плохой код иногда (smile) Ошибаться может и тот кто пишет, и тот кто ревьювит. Арбитры помогут разрешить, если самим не получается, но лучше прислушиваться к позиции оппонента.

Самый главный принцип

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

Знать ответ, за что мы сегодня получили свою ЗП.

Сделать системы подобной сложности можем только вместе. Как и построить Dream Team.

P.S. Что будет за нарушение правил? //завязывает узел линча приговаривая: демократия, демократия :) Шутка. В каждой шутке... :) Правила пишутся и дополняются совместно :) Фидбек приветствуется.

About

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

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published