я тут мимо проходил, но нельзя же просто взять, и пройти мимо

"если менеджмент не понимает, что держать 1С на сервере 10-ей давности это неправильно, то это не задача ДевОпса клянчить, доказывать и продавать"

я менеджер, продакт менеджер.  и я не понимаю, что неправильного в десятилетнем 1С если он работает.  и именно что задача ДевОпса мне объяснить про секурити апдейты, про мейнтенанс кост (что плавный регулярный апгрейд на дистанции дешевле), про альтернативы, про риски.  

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

и дальше я уже это всё сложу с другими данными (которых у ДевОпса нет, и это нормально) и приму решение что будем делать.

про внедрение чего угодно - 1. чтобы что это нужно?  2. как считать, что это "чтобы что" выполняется? 3. что даёт бизнесу это "чтобы что" (и как это посчитать)?  4. сколько это стоит единоразово и операционно?

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

что задача ДевОпса мне объяснить про секурити апдейты, про мейнтенанс кост (что плавный регулярный апгрейд на дистанции дешевле), про альтернативы, про риски.  
это его экспертиза, я его нанял именно потому, что у меня такой экспертизы нет
Есть различия между экспертной оценкой и продажей (доказыванием). Если для вас, ваш девопс, является экспертом, то и выводы эксперта по смене чего-либо вы должны принимать. А не заставлять девопса продавать.
Проще говоря, ваш девопс довёл до вас сведения, почему стоит заменить 10-ний сервер с 1С, далее, вы в соответствии с и дальше я уже это всё сложу с другими данными (которых у ДевОпса нет, и это нормально) и приму решение что будем делать и примите решение.
Это нормальный процесс.
Но если вся база 1С упадёт без возможности восстановления, то это не фейл девопса, потому что он плохо продавал (убеждал), это вина менеджмента, который сделал неправильный прогноз.

То есть, есть разница, между продать и объяснить.
Объяснить - дать свою экспертную оценку как член команды Компании.
Продать - тут и так всё понятно.
Повторюсь, я против именно продавания, как единственно фактора под внедрению чего-то нового. Особенно, когда разговор идёт о самом процессе производства продукта, а не ответвлений, по типу - стартап.

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

Если вся команда умеет так, то это бустит продукт, ибо затраты на коммуникацию снижаются, фокус (=эффективность) улучшается.

И правильно сделал, что не прошёл мимо )

Если не умеет - ну, задача менеджеров научить.  Ну или нет, можно ведь по-разному дела делать 🙂

Согласен на 146%. Когда речь идёт о продаже каких-либо процессов, продукта и чего-то другого вне структуры компании.
Иначе, имхо, это жиза.
Иначе всё упрётся в том, что процесс продажи займёт столько времени, сил и просто унижений (продай мне ручку), что инициатива по продвижению новых интересных и полезных фич, будет просто игнорится и компания перейдёт в фазу стагнации.

Я с тобой согласен. Эксперт должен уметь доносить ценность своих решений. В том числе через критику. За то и деньги платят.

Ник, доносить, это продавать или выдавать экспертное мнение?

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

Хорошо. А зачем тогда прослойка менеджмента? Не проще ли цепочку сделать проще?
специалист ->техлид-аукционер (гендир)?

Конструктивный диалог начинается с согласия о проблеме.  Если нет согласия, что проблема вообще есть, что она важная - ну дальше будет тяжко.

Иерархия менеджмента нужна из-за объёмов работ и технологических ограничений человеческого мозга 🙂

Подход "смотрите какое дешёвое решение я уже проверил" тоже неплохо работает, потому что все любят низковисящие фрукты.

В кейзе ДевОпса кажется, что он именно что просто бросает в эфир мысль "давайте все будем писать документацию", ну и нет никаких triggering points эту мысль подхватывать.

@i_tsupko намекаю тебе, что со следующим вопросом можно прийти к Руслану @rkosolapov и Максиму @maxlapshin )

Ну может он прав, просто не хватает именно коммуникативных скиллов, контекста-то маловато.

Ну в смысле нам сложно судить, мало данных у нас.  Бывают же команды где всё плохо 🙂

но если я, как специалист в своей области, делаю
Выработать решение, объяснить его всем, выдержать критику, провести эксперименты, сделать работающий прототип, объяснить ценность и замотивировать, научить людей работать с этим решением, встроить его в общий процесс.
через менеджмент или сам?
Если сам, то зачем менеджмент нужен, если на пути принятия решения стоит еще аналоговый приёмник, который может на выходе поменять входные параметры?
Если через менеджмент делаю, то я тем более не понимаю, а что будет делать менеджмент, если всё сделано за него.
====
Вот выше был контент, о том. что часть разработчиков не хочет писать документацию.
Как вы думаете, какая функциональная роль должна наладить данный процесc?
Техлид, техпис или продуктовый менеджер, например?
В кейзе ДевОпса кажется, что он именно что просто бросает в эфир мысль "давайте все будем писать документацию", ну и нет никаких triggering points эту мысль подхватывать.
И не подхватят. Потому что девопс и менеджер отличаются по самому главному - владению административными рычагами.