[Программирование, GitHub, Управление разработкой, Удалённая работа] «Конституция» для разработчиков: как страничка на GitHub помогает нам не ругаться уже год

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
24-Июл-2020 15:30

Цитировать

Год назад моя команда выросла: усложнялась бизнес-логика, по сути, мы делились на три подкоманды — в каждой были как новички, так и те, кто работал в компании годами. Подкоманды сфокусировались на своих направлениях, и хотя все пилили биллинг, перестал работать принцип общей зоны ответственности. Да и практики, которые работали у «старичков», не всегда подходили новому коллективу.

Обычно для сплочения команд мы практикуем выезды: ребята, в остальное время работающие на удаленке из своих городов, собираются в одной точке мира. Днем вместе проходят часть спринта, вечером вместе развлекаются. Но сроки поджимали, поэтому мы пошли другим путем. Вот что мы придумали — и кажется, такой подход может использовать любая команда, в которой нет авторитарного управления.
Спасибо Рэю за идею
Весной 2019-го вокруг только и было разговоров, что о книге «Принципы. Жизнь и работа» от Рэя Далио. Слышал о ней и Алексей Катаев — он же «Тимлид Леонид» и наш тогдашний тимлид.

Рэй Далио? Кто это?

SPL

В 1975-м основал инвестиционную компанию Bridgewater Associates. К 2010-м из конторы с офисом в одной из комнат съемной квартиры она постепенно превратилась в пятую по значимости инвест-организацию в США. А сам Рэй вошел в список 100 самых богатых людей в мире.
Звучит как история сына маминой подруги, но в книге Далио утверждает, что добился всего, потому что анализировал свои ошибки и сформулировал важные жизненные принципы, которым следовал.

Лёша пришел в биллинг, чтобы наладить процессы. У него было четкое видение того, какой должна быть команда — и умение убеждать. Когда все заработало, он пошел на повышение. А перед уходом предложил сформировать контракты и закрепить работу уже отлаженных процессов в команде, написав «правила жизни» для команды разработки. Новый тимлид поддержал идею — и завертелось.
Для начала мы почитали те самые принципы Далио. Всего их 16, но чтобы узнать все, надо купить книгу смысл можно понять и по этим четырем.

Примите реальность и работайте с ней.
Создайте корпоративную культуру, в которой допустимы ошибки, но недопустимо не учиться на них.
Выявляйте проблемы и не миритесь с ними.
Используйте инструменты и утвержденные процедуры, чтобы регламентировать выполнение работы.

Пафосно, конечно. Но мы решили попробовать адаптировать их под себя. Лёша набросал список из 10 принципов, а команда дополнила его, доведя общее число тезисов до 43. Завели репозиторий на гитхабе: символично, что правила работы будут хоститься там же, где и ее результат.

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

Мы договаривались на берегу. В этом и была задумка Лёши.
В процессе выяснилось, на что мы смотрим по-разному, но после нескольких дней активного обсуждения у нас появился релиз-кандидат.

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

Огласите весь список, пожалуйста
Мы разбили нашу «конституцию» на две части: 12 общих правил жизни и поведения в команде, плюс 15 технических принципов. Текст довольно длинный, поэтому основной его объем скроем под спойлерами. Орфография и пунктуация сохранены в оригинале.
Принципы работы

1.1. Мы следуем принятым принципам, независимо от согласия с ними
Персональное несогласие — не причина отступать от принципов. Тем не менее, можно начать обсуждение любого принципа, если изменились обстоятельства и он перестал быть полезным.

Еще 11 пунктов

SPL

1.2 Мы открыто говорим о проблемах и рисках
Не согласен с техническим решением или план невозможно выполнить — скажи. Сломал базу или профакапил сроки — скажи сразу. Тимлид пришел с дурацким предложением — не молчи. Часто кажется, что проще согласиться или промолчать. Помни, что это приведёт к ещё большим проблемам позже.

1.3 Мы непредубеждены
По-максимуму избавляемся от эго. Не доказываем, кто прав. Не думаем о личной выгоде. Не боимся выглядеть глупо. Помним, что часто мы неправы. Искренне стараемся понять оппонента. Не спорим впустую. Забываем о личном отношении. Цель — найти лучшее решение.

1.4 Мы не делаем ничего зря
Постоянно боремся с потраченным впустую временем: задача не принесет пользу, новый процесс нужен только менеджеру, бессмысленная встреча, ненужная кнопка. Мы — борцы с мудой. Увидел муду — уничтожь.

1.5 Лучше не стесняться и спросить, чем потом долго чинить

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

1.7 Мы не оставляем белых пятен
Мы избегаем абстрактных и не до конца понятных формулировок. Задаём вопросы, ресёрчим, высказываем сомнения. Потратим время сейчас — сэкономим потом.

1.8 Мы даём друг другу честную обратную связь
Давать честный фидбек — трудно, получать — тоже. Мы осознаём пользу обратной связи, боремся с собой и учимся давать и принимать фидбек. Мы говорим прямо, не используем намёки и абстрактную критику.

1.9 Мы доверяем друг другу и можем положиться друг на друга

1.10 Наша цель — счастливые заказчики
Мы работаем, чтобы ученики получили свои уроки, преподаватели — зарплаты, компания — прибыль. Остальное вторично: задачи, графики, тикеты, обращения. Мы не зарываемся в коде ради кода, рефакторинге ради рефакторинга, планах ради планов и презентациях ради презентаций. Мы не делаем что-то, потому что “так правильно”, “так написано в книжке” или “я всегда так делал”. Помним о цели и делаем то, что максимально приближает к ней.

1.11 Хорошо бы, надо бы, было бы неплохо
Мы не произносим такие фразы впустую. Видишь возможное улучшение — впиши в план, создай карточку, найди ответственного, а лучше — сделай сам.

1.12 Мы не меняем приоритеты спонтанно
Приоритеты не могу меняться внезапно. Требуются веские аргументы и согласования с заинтересованными сторонами.

Технические принципы

2.1. Мы думаем о последствиях
Перед сложной выкаткой или миграцией мы думаем, что будем делать, если всё пойдет не так. Делаем бекапы, скрипты отката, оцениваем риски падения. Отгоняем мысли “ай, пронесёт, всё будет ок”.

Еще 13 пунктов

SPL

2.2 У нас не должно быть мест, которые знает только один человек
Мы стремимся избегать “белых пятен” в коде и поддерживать высокий бас-фактор.

2.3 Целостность данных
При написании кода, который манипулирует с данными биллинга, особенно балансом или деньгами, мы делаем эти изменения атомарными. Если мы меняем структуру хранения или массово изменяем данные, делаем изменения обратимыми.

2.4 Простые решения лучше сложных
Качество и стабильность != сложные универсальные решения. Мы против оверинжиринга в пользу простых и понятных решений.

2.5 Мы знаем, что биллинг — не пуп земли
Биллинг — это проект, который используется многими подразделениями в Skyeng. Внося изменения в его работу, мы задумываемся о командах, работающих с биллингом или данными биллинга.

2.6 Мы кодим осознанно, а не наугад
Мы разбираемся детально, почему что-то так работает и выясняем причины, если что-то работает не так. Не добавляем строки с мыслью “это может помочь” и не удаляем строки с мыслью “кажется, это не нужно”.

2.7 У нас есть список обязательных знаний
Каждый должен потратить время и выучить вещи, которые нам важны:
— Основы работы с RabbitMQ: обменники и их типы, очереди
— БД: транзакции и уровни изоляции, блокировки
— Двойная запись в бухгалтерии
— SOLID, DI, IoC

2.8 Качество важнее скорости
Биллинг — инфраструктурная команда, а не хипстерский продукт. Наши приоритеты: стабильность и масштабируемость. “Быстро поднятое не считается упавшим” — не о биллинге. В нашем случае падение может повлечь существенную потерю денег и мы не идём на риск ради скорости.

2.9 Мы пишем код так, как будто у нас нет отдела QA
Стараемся самостоятельно протестировать код. Если не знаем как его вызвать — узнаем. Если тестировать тяжело или долго — подробно в комментариях к задаче пишем инструкцию для QA. Это увеличит время “in development”, но время до production уменьшится: задача не зависнет в непонятных статусах.

2.10 Мы тестируем код
Мы не стремимся к 100% coverage кода, но у тестируемых методов обеспечиваем 100% coverage.

2.11 Мы не аутсорсим разработку биллинга
Это увеличивает технический долг и небезопасно.

2.12 Мы с осторожностью удаляем данные
Просто так ничего не удаляем: ни поля, ни данные.

2.13 Делаем ограничения на уровне БД
Проставляем уникальные ключи, правильные типы данных. Лучше ошибка о нарушении уникального ключа, чем двойные выплаты.

2.14 Читаемость важнее скорости и краткости
Код гораздо чаще читают, чем пишут. Уделяем внимание форматированию, phpdoc, описанию, README.

2.15 Мы не переписываем проекты с нуля
Шанс того, что это хорошая идея — минимален. Мы отгоняем от себя мысли написать что-то с нуля, выбросив работающий код, проверенный годами. Мы постоянно улучшаем и рефакторим, делая говнокод кодом мечты. Избавляемся от “двойных” систем, а не создаём их.

Про последний пункт, кстати, Лёша делал отдельный доклад.

Ну окей, а как это работает?

Правила помогают быстро донести командную культуру при онбординге: новичок может понять, как все устроено, а по истории вопроса на GitHub — разобраться, почему оно так, как был принят тот или иной принцип и что о нем думал конкретный коллега.
Принципы сделали команду более открытой — мы перестали срезать острые углы. Ввели оценку 360, стали честнее давать фидбек и активнее использовать его: каждый член команды смог узнать свои сильные и слабые стороны по мнению других. Многие что-то поменяли по итогу.
Мы поменяли модель взаимодействия с заказчиками — четко зафиксировали: никто не выполнит задачу, не разобравшись в сути. И теперь на техническом ревью (созвон, на котором обсуждаются новые задачи) начинается с того, все ли понимают, для чего мы это делаем. Если команда не понимает явной пользы, даже СТО (сейчас это тот самый Лёша) не может рассчитывать на моментальное «Будет сделано!». При этом иногда по ходу обсуждения мы усложним задачу для себя, но зато будем уверены, что избежали проблем через полгода. А иногда вообще докажем заказчику, что ее не надо делать.
Наконец, так проще принимать решения и разрешать конфликты. Это экономит время: если обсуждение затягивается, спор идет вокруг одного и того же, мы всегда можем подсмотреть — «а как там в наших принципах». И принять решение, опираясь на них.

Что было дальше
Спустя некоторое время команда развиртуализировались на слете в Сочи. Тогда мы распечатали принципы на бумаге вроде папируса, прошили, — и каждый получил красивую брошюру, которую увез домой.

Тимлид говорит, что хотел получить на бумажной версии наши автографы кровью. Шутит, наверное.
Принципы можно менять и сейчас. Если у кого-то появляется стоящая идея, что-то не нравится или есть желание что-то добавить, любой член команды может создать реквест и устроить голосование по нему: 100% «за» и поправка внесена.

Главное — не бояться договариваться и обсуждать проблемы.
Интересно, как оно устроено у вас.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_programmirovanie (Программирование), #_github, #_upravlenie_razrabotkoj (Управление разработкой), #_udalennaja_rabota (Удалённая работа), #_dogovarivaemsja_na_udalenke (договариваемся на удаленке), #_pravila_komandy_na_github (правила команды на github), #_reshenie_konfliktov_v_razrabotke (решение конфликтов в разработке), #_komandoobrazovanie_v_it (командообразование в ит), #_blog_kompanii_skyeng (
Блог компании Skyeng
), #_programmirovanie (
Программирование
), #_github, #_upravlenie_razrabotkoj (
Управление разработкой
), #_udalennaja_rabota (
Удалённая работа
)

Профиль ЛС

Ответить на тему

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

Текущее время: 23-Ноя 00:07
Часовой пояс: UTC + 5