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

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



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

    Спасибо Рэю за идею


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

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

    Звучит как история сына маминой подруги, но в книге Далио утверждает, что добился всего, потому что анализировал свои ошибки и сформулировал важные жизненные принципы, которым следовал.

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

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

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


    Да и, если честно, так проще поддерживать и развивать все это дело.

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


    Мы договаривались на берегу. В этом и была задумка Лёши.

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

    image
    Пул-реквест должен был одобрить каждый член команды.

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


    Огласите весь список, пожалуйста


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

    Принципы работы


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

    Еще 11 пунктов
    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 пунктов
    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% «за» и поправка внесена.

    image
    Главное — не бояться договариваться и обсуждать проблемы.

    Интересно, как оно устроено у вас.
    Skyeng
    Крупнейшая онлайн-школа Европы. Удаленная работа

    Комментарии 22

      +6

      Красиво) Видимо команда слаженная, и нету выгоревших людей, разной степени токсиков и социопатов, дизбаланса в уровне навыков, и ревностного отношения к собственному коду :D К сожалению, я видел только другой мир — кровавые кранчи в комманде гениев, где каждый человек — целый отдельный домен/отдел в больших компаниях, и такими правилами можно, разве-что, извините, "подтереться". Работу нужно делать, не пере-ссориться, спасали только тим-билдинги :)

        +2
        спасали только тим-билдинги :)

        А спасали раз и навсегда, либо только на какой-то время?
          +2

          на какое-то время :D

          +1
          21 кодексо-принцип — и не упомнишь все, талмуд целый.
          может стоило сократить до 7 заповедей?
            0
            Ну оно же не на каждый день: базово, вы сначала договорились с коллегами через механику, если все идет по плану, то апеллировать к страничке и нет необходимости. Как и любой свод правил, он обеспечивается какими-то повседневными инструментами — например, с bus factor можно делиться на обсуждении задач на рабочие группы так, чтобы там был и человек с опытом в области, так и те, кто только краем уха слышал. И так по каждому пункту.
            +2

            У нас в Альфа-Банке мы это назваем "стандарты разработки" и формируются они по RFC https://www.ietf.org/rfc/rfc2119.txt


            А внутри команд пользуемся Agile манифестом и лично я при code review использую подходы Гугла https://google.github.io/eng-practices/review/ хотя у нас тоже есть правила code review

              +2
              Спасибо, интересно! Касательно подходов к код-ревью, у нас одна из команд делилась таким чек-листом, у другой вообще своя философия. Тут, как и везде, сто цветов и фломастеры разные)
              +1

              Эти "правила" работают только с правильным настроем и будут работать неправильно, если их читать с другим.


              • "Мы не делаем ничего зря" — прекрасное правило для того, чтобы все начали отрицать потраченное зря время и сделанные ошибки.
              • "У нас есть список обязательных знаний" — вообще прекрасное правило, если твое трактование одного из указанных принципов не совпадает с консенсусом команды, тебя могут объявить неучем и попросить самовыпилиться?
              • "Мы не переписываем проекты с нуля" — неоднократно попадал в ситуацию, когда легче переписать небольшой компонент с нуля и постепенно перетащить на него всех клиентов старого. Одновременно с "мы следуем принципам и не спорим" — вообще волшебно.
              • "Мы не стремимся к 100% coverage кода, но у тестируемых методов обеспечиваем 100% coverage" — никакие проценты statement coverage не говорят о качестве этого покрытия. Даже если это coverage одного метода. У меня даже картинка есть на это.
              • "и не удаляем строки с мыслью “кажется, это не нужно" — порой, это единственный способ узнать, что это действительно не нужно.
              • "Читаемость важнее скорости и краткости" — только до тех пор, пока скорость не важнее читаемости и краткости.

              Ну и в целом какая-то мешанина принципов для разработчиков и для непонятно кого:


              • "Мы не аутсорсим разработку биллинга" — счастливый заказчик попросит, и будете аутсорсить.
              • "Мы не меняем приоритеты спонтанно" — счастливый заказчик попросит, и будете 10 раз в неделю менять.

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

                +2
                Ну и в целом какая-то мешанина принципов для разработчиков и для непонятно кого

                Насколько я понял из статьи — это мешанина принципов для одной конкретной команды. Отсюда специфика типа "не аутсорсим биллинг". Это команда по разработке биллинга в продуктовой конторе — откуда там возьмется "счатстивый заказчик"?


                Основой посыл статьи — не трансляция принципов, которые сильно специфичны (они, кстати, под катом — я туда в первом прочтении статьи даже не смотрел). А в подходе, который таки универсален.
                Выжимка из статьи: "Собираем все негласные договоренности и принципы в команде — и записываем в документ, на который можно сослаться".

                  +1
                  Добрый день, вы правы в том, — это специфика конкретной команды в конкретной компании. Так что это скорее история про «мы тут попробовали, вот такая штука получилась, может кому-то пригодится и захочется адаптировать у себя».

                  Слепо копировать опыт, конечно, не стоит) Часть практик (например, про не переписывание с нуля) стала, по сути, договоренностью и передачей опыта старичкам новичкам — ну потому что как-то пробовали, но оказалось, что всем проще и выгоднее договариваться с бизнесом на выделенное время для закрытия техдолга в спринтах.

                  Одновременно с «мы следуем принципам и не спорим» — вообще волшебно.

                  Как и любой принцип в списке, его можно поменять, вынеся свою версию на голосование и собрав 100% за. В комментариях ниже привели отличный аналог из авиации: ты не выпячиваешь свое эго, но и не обязан молчать. Если что-то не ок, не критикуешь, а предлагаешь — и если команда согласна, то вы вносите поправку. В истории этого репозитория были такие случаи.

                  Ни одни правила не замещают с собой коммуникацию,
                    +1
                    Мне кажется, что переносить надо не имеющуюся версию манифеста, а именно процесс его составления (в качестве базового варианта — какие-то первые версии манифеста). В текущем виде с ним согласятся, потому как он за всё хорошее против всего плохого и не соглашаться с ним некузяво, но выполнять не будут. А опыт составления группого договора бесценен.
                  +4
                  Я бы с чисто практической точки зрения поменял первый пункт «Мы следуем принятым принципам, независимо от согласия с ними» на нечто близкое к традициям авиационных CRM (cabin resource management): «Выполняй, или объясняй». То есть если ты выполняешь принятые правила или процедуру — это по-умолчанию OK. И ты можешь отступать от утвержденной процедуры при условии (!) что можешь объяснить причину и цель такого действия. В идеале — до того, как выполнение нестандартной процедуры началось («брифинг»), но можно и после — если действие неотложное («сообщение о проблеме»). При этом, разумеется: «не успел», «не подумал», «думал, прокатит» и все в таком духе — надлежащими объяснениями не являются.

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

                  Вообще, жутко полезно хотя бы по-диагонали посмотреть номативку атомщиков и летчиков. Они там по краю ходят — в том смысле, что можно одной простой ошибкой угробить сразу много народа. Поэтому жизнь их заставляет придумывать всякие интересные штуки для предотвращения неприятных ситуаций. Напрямую в разработку это, конечно, не перенести — иначе разработка упадет под гнетом предотвращения рисков и стоить будет о-го-го сколько! Но отдельные элементы — это прямо вот что доктор прописал. Особенно, для ответственных приложений и сервисов…
                    0
                    Вообще, жутко полезно хотя бы по-диагонали посмотреть номативку атомщиков и летчиков.

                    Спасибо за интересную наводку. А можете поделиться хорошими, на ваш взгляд, примерами, если не сложно?
                      +6
                      Я лично с большим вниманием прочитал гайды по CRM (начать можно с видео и статей Дениса Оканя (https://denokan.livejournal.com/). Там много интересного как раз о правилах и процедурах: зачем, почему, как учить, и т.д. Плюс даются паттерны, как обсуждать проблему в условиях высоких рисков и ограниченного времени, не скатываться в борьбу характеров, и т.д.

                      Из авиации же — «принцип черной кабины»: нормально работающая система не должна привлекать к себе внимание или требовать постоянных проверок. Однако, любые отказы и аномалии должны быть явно и однозначно обозначены персоналу.

                      У атомщиков я с удовольствием стащил понятие «максимальной проектной аварии (МПА)», и принцип построения системы защиты так, чтобы в случае МПА все были живы и здоровы. Оттуда же — аварийные действия персонала по приведению системы в безопасное состояние не должны требовать сложных решений и рассудочных действий. В идеале — нажал кнопку аварийной защиты — и оно само, уже тебя ни о чем не спрашивая — сбросит, заглушит, расхолодит, и т.д. Потом в спокойной обстановке будете разбираться, что к чему было…

                      Моя адаптация этого принципа в работу была примерно в 2004 году — инструкция по переводу довольно большой ИТ-системы на работу в резервном режиме (другой сервер, резервная серверная примерно в 20 км). Эта инструкция содержала два пункта: первый — зайти пользователем таким-то, пароль такой-то на сервер IP такой-то. Второй — выполнить команду такую-то, переход системы в резервный режим произойдет в течение 3-5 минут автоматически. И мне было не важно, кто будет это делать — программист, администратор, или хотя бы слесарь КиП: чье тело найдут по телефону, тот и будет делать! Не важно, хочет ли он спать, пил он вчера или нет, знает ли особенности системы, и т.д. — если команда прошла, остальное от него не зависит.

                      P.S. Реальный переход в резервный режим был один раз примерно за 6 лет работы.
                    0
                    Это уровень, безусловно. Чем то напомнило книгу о том, как надо общаться в IT команде, не помню какого автора, но обложка была красная. Был бы благодарен если бы кто напомнил.
                      0

                      В списке правил есть конфиденциальная информация? Хочется прочесть все 43 пункта в репозитории. Планируете ли сделать репозиторий с правилами публичным?

                        +1
                        Привет!

                        Хочется прочесть все 43 пункта в репозитории

                        Наверное, не до конца мы четко написали — в общем, исходно было 43 пункта, но в процессе обсуждений, приоритизации, голосований и этого всего какие-то пункты укрупнялись, какие-то отвергались. И список похудел до 27.

                        Планируете ли сделать репозиторий с правилами публичным?

                        Тк команда им пользуется, в ней и в правилах периодически происходят изменения — даже не знаем… Но если вопрос в том, как с кем-то поделиться без обвязки остальной историей, то Лёша Катаев выкладывал на hackmd для своего доклада копию.
                          +2

                          Да, верно, не совсем очевидно стало, что было 43, а осталось 27, и все эти 27 представлены в статье. Спасибо за уточнение.


                          Спросил про публичность репозитория именно из-за того, что думал, что есть еще что-то в списке. Если же нет, то вопрос отпадет. Не знаю как другим читателям, но мне достаточно статьи и этой ссылки на hackmd. Спасибо

                        0
                        Напомнило классику
                          0
                          Как-то мы у себя тоже писали «абстрактные правила» вроде ваших. Конечно, мы попроще подошли и не работали настолько тщательно над ними. Но в итоге, мы их повесили на стену и благополучно забыли в практическом плане. По ревью кода и оформлению у нас тоже есть регламент. Но если сам ревьювер не соблюдает их при разработке… Потому что не он их принимал… В общем, правила — это конечно хорошо, но их нужно еще и соблюдать. С аутсорсингом вообще в этом отношении все плохо.

                          Лучше всего работают технические регламенты-инструкции вроде того, как что настроить, чтобы работало.
                            0
                            Нельзя писать абстрактные правила. Даже если для «повесить на стену» есть выжимка на листе A4 — где-то должен быть дизайн-документ с объяснениями, ради чего то, или иное правило вводится.

                            Крайне частая ошибка — это пытаться документом изменить практику разработки. Докладываю — практика документами не меняется! Даже, блин, в армии — начальство пишет документы про одно, в низах делается другое (хотя субординация, и «служи — по уставу!»). Очень советую почитать что-нибудь про change management: нужно, чтобы сначала появилась потребность в определенном правиле, чтобы эта потребность стала осознанной, чтобы были ресурсы для выполнения правила — и только потом можно писать правило в документ.

                            Обязательно проверяйте — если выполняя ваши правила можно устроить «итальянскую забастовку», значит — правила плохие (не жизненные, работать не нарушая их — невозможно) и их следует переделывать.
                            +1
                            Самое главное чтобы правила касались всех без исключения в равной мере. Иначе будет «Друзьям — всё, врагам — закон», то есть руководство будет использовать правила чтобы спрашивать, а самим на них будет плевать.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое