Pardon my French. точнее English…. Но наболело. Вообще-то я зарекался писать на:
В год века пятьдесят шестой
Я, Франсуа Вийон, школяр,
Бег мыслей придержав уздой
И в сердце укротив пожар,
Хочу свой стихотворный дар
Отдать на суд людской, – об этом
Писал Вегеций, мудр и стар, -
Воспользуюсь его советом!
Вообще-то есть более прямой и непристойный перевод, но за него тут могут забанить.
Итак, для непонятливых, что же это за зверь такой - Area Ownership? Вот есть у вас предположим проект. А в нем куча компонент. А вот ведь как подло устроил Всевышний этот мир - вам обязательно надо, чтобы каждую компоненту при случае было кому починить… Но есть в этом мире и что-то хорошее. У каждой компоненты потихоньку появляется "хозяин" - "owner", который таки знает как её чинить.
Вот только вопрос, а это и правда хорошо?
Начнем с плюсов. Код вашей системы действительно в любой момент (если только парень не загорает на пляже в Мексике под пальмами) могут починить. Нет, правда, МОГУТ ПОЧИНИТЬ. Смейтесь, смейтесь, но это и правда очень важно.
А куда вам деваться? Это бизнес, детка. Или ешь ты, или едят тебя. А чтобы продолжать есть, "the show must go on!" - эта хрень должна работать. А ведь ты сам вначале нанимал дешевых студентов, которые тебе нагородили такое… ну, это самое… для чего ты теперь вынужден нанимать или растить экспертов....
Сантехник с учеником приходят к клиенту, а у того весь подвал залит плохо пахнущей жидкостью с кусочками… ну, вы догадались чего. Сантехник засучивает рукава и ныряет туда с головой. Через пару минут он выныривает и кричит:
- Ключ на пять!
Ученик подает ему ключ, тот ныряет обратно, через секунды раздаются хлюпающие звуки, все д-о уходит вниз. Сантехник гордо идет к ученику, стряхивая с себя кусочки понятно чего.
- Учись, сынок. А то так и будешь всю жизнь ключи подавать!
Вот и ваша проблема номер один. Такой человек, конечно, готов не только ключи подавать, но и стоит он дорого. А ваш CEO всю жизнь управлял цехом разлива Кока-Колы. Для него ценный специалист сидит на высоком стуле и следит, чтобы в проплывающих мимо него бутылок не оказалось дохлой крысы. Вы как, готовы объяснить, почему вашему "сантехнику" нужно платить так много? Ну, когда есть так много молодых и ретивых за куда меньшие деньги? Конечно, после опять понадобится сантехник, так поди ж, обьясни это своему лимонаднику, который хорошо если и правда кокой не закинулся, для более ярких корпоративных вижн (vision). И я не про лимонад.
Но даже это не самое худшее. У вас-то фирма обычная, не Гугл, чай, обеды сотрудникам не готовит, и вот едет этот ваш уникум на обед, врезается в школьный автобус, и это трагедия. Нет, у мира своя, у вас своя. У вас некому чинить этот код. Говорят, в созданном в Новосибирске Русском Алгоритмическом Языке РАЯ было ключевое слово для окончания цикла - "пц". Вот… это оно.
Некоторым решением является размазывание "владения" между несколькими людьми. Ну, вот, есть у каждой вашей компонеты два владельца, которые могут её чинить. Ну, и пусть один из них врезается в автобус, у нас второй есть! Увы, а ведь эти заразы дружить будут. И в одной машине окажутся!
А еще надо сделать так, чтобы оба ПО ОТДЕЛЬНОСТИ могли чинить, а не один лидером, а другой прицепом. Тогда ведь не поможет. А чтобы этого не случилось, нужен очень хороший менеджер. А хорошего менеджера найти о-очень трудно. Почти как казначея.
"Недаром говорят, что хорошего казначея трудно найти. Мы его потом долго искали,"
Богу - Божье, книга 2 Маска - я тебя знаю, Эли Эшер
Нет, правда, хороший менеджер - это чудо. При найме его не распознать. Найти его нереально трудно. И как вам без него управляться со своими умниками?
Помер инжерер. И отправили его в ад. Ну, взглянул он привычно на свое performance review, поплакал в уголке, и отправился куда послали.Через два года Бог явился в ад с инспекцией. А там везде кондиционеры, свежий воздух, черти на зеленых лужайках мучают грешников корпоративными тренингами, а кабинет Дьявола вообще больше похож на гольф-курс. Бог в гневе:- Это как???!!!- Так ты ж сам к нам инженера отправил!- Это ошибка! Вертай назад!- Не отдам!!!- Да, ты что, совсем сдурел? На понимаешь, кому перечишь??? Засужу!- Ну, и где ты найдешь адвоката?
И возникает огромный соблазн вместо одного умника нанять шесть балбесов. Они хоть вместе даже в один миниван не влезут. Вот только смогут ли они вашу систему починить?
А вы что думаете?
Комментарии (12)
CodeRush
11.11.2021 01:52Думаю, что оставшаяся без Directly Responsible Individual часть проекта обязательно сломается скорее раньше, чем позже, и вместо одного дорого умника понадобится пять, чтобы либо оперативно разобраться, починить, снова назначить DRI, и реанимировать эту часть, либо ударным трудом переписать, чтобы все снова заработало хоть как то.
Видел несколько успешных проектов с размазанным владением, но в них всегда был «дежурный DRI на сегодня», и было их там не шестеро средних, а трое сильных, которые сообща владели дюжиной проектов разного размера, и могли перебрасывать и свои силы, и силы своих ассистентов уровней поменьше с тех мест, где уже нормально, на те, где все еще все в огне и мы в аду.
Проблема автобусного фактора вокруг единицы у очень многих ключевых сотрудников, от которого страдают и работодатель, и сами ключевые сотрудники — она понятная, и решается в основном заваливанием этих сотрудников плюшками (чтобы не уходили к конкурентам), и стратегическими длинными отпусками в тот момент, когда ключевые сотрудники начинают подгорать (чтобы не уезжали в Монголию пасти скот), но вот такие вот решения намного лучше работают на практике, чем попытки размазать реальное владение, которое неизбежно приводит к многократно опробованному и повторенному «общее — значит ничьё».
JordanoBruno
11.11.2021 03:55+2Вроде в "Управление проектами", а по факту пишите о довольно банальном вопросе.
Бизнесу всегда нужен ответственный за компонент/лужайку/инструмент. Чтобы было с кого спрашивать. И вполне естественно, что разбираться он будет в своем лучше остальных.
Естественно, такой человек может внезапно заболеть/запить/уволиться/уехать в отпуск и перестать быть доступным. Так как проблема стара как мир, то и решения известны:
1) Как Вы уже написали - это второй/третий/восемнадцатый человек(в зависимости от важности), знакомый с подробностями и могущий если что подхватить знамя.
2) Документация с описанием важных моментов. Считайте это бакапом. Поэтому все менеджеры делаются на тех, у кого уже есть документация и на тех, кого ждут неприятные деньки.
3) Бывает и такое, что ни первого ни второго нет. Тогда либо находят умного человека, который заново разбирается, либо все просто переделывают.
ngekht
11.11.2021 06:33А им не обязательно попадать под автобус, люди еще просто меняют место работы, уходят в декрет и на больничный или просто возникает куда лучшее для них применение чем заставлять их копаться в остонадоевшей компоненте десятый год подряд.
Короче, неосторожные и нелояльные негодяи, совершенно плюющие на проблемы бедного владельца проекта, который по какой-то причине целиком и полностью проигнорировал в общем-то неплохо проработанный во многих методиках подход к обеспечению supportability - то бишь способности продукта к поддержке и дальнейшему развитию.
Но вообще еще много интересного сделать в разработке ПО. Например не озаботиться архитектурой, или забить на управление качеством, или не париться требованиями - и во всех случаях если проект не провалится - то возникает совершенно неожиданная (tm) и удивительная зависимость от пары человек которые чудом проект сделали вопреки всем усилиям заказчика и работодателя ни в коем случае проекта не допустить :-)
Увы, продолжает встречаться куда чаще чем должно бы.
silverpopov
11.11.2021 09:10Высококвалифицированный специалист должен создавать лёгкий для поддержки код. В котором легко разберётся другой высококвалифицированный специалист.
flancer
11.11.2021 10:23"В теории нет разницы между теорией и практикой. А на практике есть." (с) Йоги Берра
silverpopov
11.11.2021 11:20На практике часто используют плохих специалистов.
flancer
11.11.2021 12:05Это компенсируется тем, что в теории часто используют высококвалифицированных.
EldarM Автор
13.11.2021 19:40Так сначала нанимают низкоквалифицированных, а затем уж ищут.... ну... сантехников.
gleb_l
Сложность систем, автоматизирующих некие бизнес-процессы, не может быть ниже сложности самих этих автоматизируемых бизнес-процессов.
Из этого вывод - хотите есть конкурентов сами - либо используйте адм. ресурс (в России можно, но опасно - проигравших, или просто не угадавших направление ветра, сажают), либо берите хитростью - то есть усложняйте бизнес-процессы. Дальше см. выше. Сложный бизнес -> сложная автоматизация -> сложные системы. Написать и поддерживать такую - нужны сложные (то есть дорогие/штучные) мозги. Дорогие/штучные <==> невзаимозаменяемые. Не сажайте КВС и второго пилота в один минивен ;)
EldarM Автор
Первое утверждение - согласен. Причем оно уже выделяет вас на нетривиальность и понимание того, что не доступно многим.
Остальное, может и правда, но не по теме. Извините. Хотя тема очень интересная и богатая.
amarao
автоматизация бывает разная. Бывает ассистирующая автоматизация, бывает замещающая, бывает реформирующая. Ассистирующая автоматизация может быть любой степени примитивности. Реформирующая, может оказаться, внезапно, проще, чем был бизнес-процесс до реформы.
ngekht
В целом вы правильно зашли с теории сложных систем, но можно было продолжить в той же канве, бо совсем рядом там же мы найдем преимущества эмержетного поведения коллектива как сложной системы против единичности/штучности даже очень качественного мозга. Русский сегмент долгое время спасал относительный избыток оверквалифицированных кадров, когда таки можно было найти своего карманного гения на разумных условиях, но все хорошее кончается, манагерам придется перестать надеяться на “джина из бутылки” который пусть за дорого, но усе решит, а начать думать головой.