Комментарии 20
Ты, говоришь, пишешь на Скале? Отлично, я назначаю тебя «владельцем» этих 30 миллионов строк на коболе, которые работают внутри эмулятора внутри виртуальной машины внутри виртуальной машины на вот том сервере устаревшей модели.
Глафирий Порфирьевич собирается покидать нас, потому что у него, увы, здоровье не то и деменция уже совсем замучила. Он тебя по-быстрому введёт в курс дела, и ты будешь владельцем этого кода — принимать в него pull-request'ы от Акакия Варфоломеевича и Эры Валериевны.
Глафирий Порфирьевич собирается покидать нас, потому что у него, увы, здоровье не то и деменция уже совсем замучила. Он тебя по-быстрому введёт в курс дела, и ты будешь владельцем этого кода — принимать в него pull-request'ы от Акакия Варфоломеевича и Эры Валериевны.
Есть более эффективная метрика для тех же целей — bus factor, сколько человек должен сбить автобус (условно покинуть команду), чтобы работа по проекту остановилась. Маленький bus factor — высокие риски, большой — высокие затраты, так как совместное владение кодом всегда дороже, чем единоличное. Если у вас хороший климат в коллективе и низкая текучка — можно стремиться к bus factor равному 2, то есть по каждому проекту/микросервису минимум 2 человека знают принцип работы и могут заменить друг друга в случае отпуска/увольнения/больничного. Мы в моей команде просто составляли табличку: проект, ответственный, дублирующий, и расписывали около 15 микросервисов на 5 человек. И для проекта хорошо, и разработчику дополнителный почёт, особенно для джунов, что они ответственны пусть за маленький, но собственный сервис.
Легко поддерживать корпоративную культуру на словах.
Когда я слышу слова «корпоративная культура», моя рука тянется к пистолету (почти (с)). Потому что слова эти — сигнал того, что идет обсуждение, как побольше состричь шерсти с простых разработчиков. И данная статья — не исключение.
когда члены команды владеют плодами своего труда, отвечают за них перед менеджерамиСлово «владеют» в предыдущей фразе — обманка. Плодами труда наемных работников в корпорации владеет корпорация, а не разработчики (не верите — попробуйте забрать с собой то, чем вы якобы «владеете»). А настоящий смысл фразы заключен во второй её части: разработчики — отвечают. Точнее, по мнению менеджмента — должны отвечать. Только вот реализовать это «отвечают» при новых методах организации разработки стало сложнее: потому что в борьбе с «человеческим фактором»(AKA bus factor) менеджмент довел процессы разработки до такого состояния, когда никто из разработчиков не контролирует целиком никакую часть написанного кода. То есть — код от разработчиков отчуждается уже в процессе написания программы, а не после её завершения.
И вот меджемент нашел, как ему кажется, хороший способ решения проблемы — «коллективное владение». То есть, по факту — коллективная ответственность, иначе говоря — круговая порука. Когда за косяки одного отвечает «команда». В отношениях между человеком и государством такая форма ответственности считается жутчайшим анахронизмом и мракобесием. Про такое государство обязательно будет сказано и написано много нехороших слов. Но вот то, что не позволено государству, почему-то позволено (и даже считается хорошим и передовым) для корпорации. Парадокс?
Спасает тут только то, что коллективную ответственность сложно формализовать. Делать это напрямую — вступать в конфликт с законом. А от всяческих попыток использовать косвенные показатели, типа предложенного в статье, спасает закон Гудхарта: если какой-то показатель начинает использоваться для управления, то эмпирическая закономерность, на которой это управление основано, перестает действовать. Потому что люди — не дураки, и способы, как сделать правильную отчетность без лишнего напряжения, они обычно находят и, причем — быстро.
«Драконы существа алчные и в драконьем языке сорок семь значений слова „мой“» /~какая-то фантошка/
В русском слово «мой» тоже… многогранно: в случаях «моя шапка» и «моя родина» — слово «мой» имеет практически противоположные смыслы.
Поэтому у меня лично в этом тексте никаких проблем слово «владеть [кодом]» не вызывает.
Автор имеет в виду «кто наполняет модуль новым кодом и гарантирует корректность вставленного», только и всего. Здесь ни намёка на то, кому и как продаётся код, кем и зачем эксплуатируется.
И несуразица с «коллективным владением» так же просто означает, что в пределах одного, например, файла, отметились несколько разработчиков. В большинстве ситуаций локализация бага до строки эквивалентно выводит на косячника. В меньшинстве ситуаций модификация одного провоцирует ранее скрытый баг другого, но это существенно реже и таки поддаётся локализации.
Что касается ложных KPI или приспособления хитрого существа оптимизировать KPI вместо оптимизации производства, то да, проблема большая — мало кто может выразить разработку через некий релевантный цели index.
В русском слово «мой» тоже… многогранно: в случаях «моя шапка» и «моя родина» — слово «мой» имеет практически противоположные смыслы.
Поэтому у меня лично в этом тексте никаких проблем слово «владеть [кодом]» не вызывает.
Автор имеет в виду «кто наполняет модуль новым кодом и гарантирует корректность вставленного», только и всего. Здесь ни намёка на то, кому и как продаётся код, кем и зачем эксплуатируется.
И несуразица с «коллективным владением» так же просто означает, что в пределах одного, например, файла, отметились несколько разработчиков. В большинстве ситуаций локализация бага до строки эквивалентно выводит на косячника. В меньшинстве ситуаций модификация одного провоцирует ранее скрытый баг другого, но это существенно реже и таки поддаётся локализации.
Что касается ложных KPI или приспособления хитрого существа оптимизировать KPI вместо оптимизации производства, то да, проблема большая — мало кто может выразить разработку через некий релевантный цели index.
В общем-то, по поводу этого конкретного текста я с вами согласен: конкретно в нем «владение» — это чисто технический термин в рамках технологии управления, краткое обозначение для делегирования отвественности и права принятия решений.
«Но есть нюанс»(с) — слова «корпоративная культура» в заголовке. Корпоративная культура — она ведь имеет две стороны: включает в себя не только технологии организации производства, но и внутрикорпоративный PR — тоже. И именно в контексте PR слово «владеть» имеет нехороший оттенок: очень уж оно подходит, для того чтобы ездить по ушам наемным работникам, чтобы внушить им ложное чувство общности их интересов с интересами корпорации. И цитата «почти из Ганса Йоста» из начала, да и, собственно, весь мой первый комментарий как раз были навеяны этим самым нюансом.
«Но есть нюанс»(с) — слова «корпоративная культура» в заголовке. Корпоративная культура — она ведь имеет две стороны: включает в себя не только технологии организации производства, но и внутрикорпоративный PR — тоже. И именно в контексте PR слово «владеть» имеет нехороший оттенок: очень уж оно подходит, для того чтобы ездить по ушам наемным работникам, чтобы внушить им ложное чувство общности их интересов с интересами корпорации. И цитата «почти из Ганса Йоста» из начала, да и, собственно, весь мой первый комментарий как раз были навеяны этим самым нюансом.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А можно и проще. Как только кто-то меняет модуль (метод, класс, файл, каталог, проект целиком) — он становится полностью за него ответственнымю А то, понимаешь, написал ты милион строк. Пришел Вася, поменял десяток. Все упало непонятно как. Кто крайний?
Я причем на полном серьезе. Именно так наша команда и работает — кто последний менял файл, тот за него и отвечает.… в теории.
Я причем на полном серьезе. Именно так наша команда и работает — кто последний менял файл, тот за него и отвечает.… в теории.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это порождает другую проблему, ни кто не хочет менять файлы, а лепит сбоку свои костыли. Так появляются раздельные калькуляторы стоимости для сайта, и каждого из отделов, и ещё один для личного кабинета.
НЛО прилетело и опубликовало эту надпись здесь
Если подойти с точки зрения управления (поверхностно), то получается картина:
Делим проект на куски, каждому куску назначаем ответственного.
Вернее двух ответственных (помним про автобус)
Соответственно, каждое дополнение должно пройти через дополнительных двух человек (в случае, если изменяет у себя — через одного)
В принципе, нормально. Один написал, другой проверил.
Либо поверил на слово, но принял на себя ответственность.
- Надо ввести ввести отчётность — кто сколько новых кусков добавил и тоже ставить их на учёт.
То есть к выполнению задачи добавляется сразу ее проверка и только после — тестирование. При этом у нас идёт простой по времени между "сделал" и "проверили", соответственно увеличивается время выпуска продукта. В случае "коротких" задач (3 часа), мы можем надеяться, что правка будет принята завтра (проверяющий доделал задачу и переключился на проверку). В случае длинных задач, проверяющий будет выпадать из контекста, то есть работа с короткими задачами оптимальна. В принципе на скрам должно ложиться неплохо, особенно, если совместить с тестированием. Но с ним не совместить — качество и адекватность кода тестировщик не проверит.
Все таки добавляем ещё один столбик и таки двигаем время выхода продукта, либо уменьшаем количество фич в спринте.
Но при этом убиваем взаимозаменяемость в команде.
Но как бы добавляем качество.
Быстро, дорого, хорошо — выбираем дорого и хорошо. Это либо разработка с гарантированным качеством, либо подготовка к последующей поддержке по sla.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Одна особенность корпоративной культуры, необходимая для благополучия кодовой базы