Комментарии 12
Сложность систем, автоматизирующих некие бизнес-процессы, не может быть ниже сложности самих этих автоматизируемых бизнес-процессов.
Из этого вывод - хотите есть конкурентов сами - либо используйте адм. ресурс (в России можно, но опасно - проигравших, или просто не угадавших направление ветра, сажают), либо берите хитростью - то есть усложняйте бизнес-процессы. Дальше см. выше. Сложный бизнес -> сложная автоматизация -> сложные системы. Написать и поддерживать такую - нужны сложные (то есть дорогие/штучные) мозги. Дорогие/штучные <==> невзаимозаменяемые. Не сажайте КВС и второго пилота в один минивен ;)
Первое утверждение - согласен. Причем оно уже выделяет вас на нетривиальность и понимание того, что не доступно многим.
Остальное, может и правда, но не по теме. Извините. Хотя тема очень интересная и богатая.
автоматизация бывает разная. Бывает ассистирующая автоматизация, бывает замещающая, бывает реформирующая. Ассистирующая автоматизация может быть любой степени примитивности. Реформирующая, может оказаться, внезапно, проще, чем был бизнес-процесс до реформы.
В целом вы правильно зашли с теории сложных систем, но можно было продолжить в той же канве, бо совсем рядом там же мы найдем преимущества эмержетного поведения коллектива как сложной системы против единичности/штучности даже очень качественного мозга. Русский сегмент долгое время спасал относительный избыток оверквалифицированных кадров, когда таки можно было найти своего карманного гения на разумных условиях, но все хорошее кончается, манагерам придется перестать надеяться на “джина из бутылки” который пусть за дорого, но усе решит, а начать думать головой.
Видел несколько успешных проектов с размазанным владением, но в них всегда был «дежурный DRI на сегодня», и было их там не шестеро средних, а трое сильных, которые сообща владели дюжиной проектов разного размера, и могли перебрасывать и свои силы, и силы своих ассистентов уровней поменьше с тех мест, где уже нормально, на те, где все еще все в огне и мы в аду.
Проблема автобусного фактора вокруг единицы у очень многих ключевых сотрудников, от которого страдают и работодатель, и сами ключевые сотрудники — она понятная, и решается в основном заваливанием этих сотрудников плюшками (чтобы не уходили к конкурентам), и стратегическими длинными отпусками в тот момент, когда ключевые сотрудники начинают подгорать (чтобы не уезжали в Монголию пасти скот), но вот такие вот решения намного лучше работают на практике, чем попытки размазать реальное владение, которое неизбежно приводит к многократно опробованному и повторенному «общее — значит ничьё».
Вроде в "Управление проектами", а по факту пишите о довольно банальном вопросе.
Бизнесу всегда нужен ответственный за компонент/лужайку/инструмент. Чтобы было с кого спрашивать. И вполне естественно, что разбираться он будет в своем лучше остальных.
Естественно, такой человек может внезапно заболеть/запить/уволиться/уехать в отпуск и перестать быть доступным. Так как проблема стара как мир, то и решения известны:
1) Как Вы уже написали - это второй/третий/восемнадцатый человек(в зависимости от важности), знакомый с подробностями и могущий если что подхватить знамя.
2) Документация с описанием важных моментов. Считайте это бакапом. Поэтому все менеджеры делаются на тех, у кого уже есть документация и на тех, кого ждут неприятные деньки.
3) Бывает и такое, что ни первого ни второго нет. Тогда либо находят умного человека, который заново разбирается, либо все просто переделывают.
А им не обязательно попадать под автобус, люди еще просто меняют место работы, уходят в декрет и на больничный или просто возникает куда лучшее для них применение чем заставлять их копаться в остонадоевшей компоненте десятый год подряд.
Короче, неосторожные и нелояльные негодяи, совершенно плюющие на проблемы бедного владельца проекта, который по какой-то причине целиком и полностью проигнорировал в общем-то неплохо проработанный во многих методиках подход к обеспечению supportability - то бишь способности продукта к поддержке и дальнейшему развитию.
Но вообще еще много интересного сделать в разработке ПО. Например не озаботиться архитектурой, или забить на управление качеством, или не париться требованиями - и во всех случаях если проект не провалится - то возникает совершенно неожиданная (tm) и удивительная зависимость от пары человек которые чудом проект сделали вопреки всем усилиям заказчика и работодателя ни в коем случае проекта не допустить :-)
Увы, продолжает встречаться куда чаще чем должно бы.
Высококвалифицированный специалист должен создавать лёгкий для поддержки код. В котором легко разберётся другой высококвалифицированный специалист.
Area Ownership: Good, Bad or Ugly?