Comments 14
Не осилил дальше второго абзаца: очень трудно читать, когда так много несвязанных списков. Непоняино, что хочет автор. Думаю, что у топов было также.
А можете привести пример как было бы лучше?
И да, указанное в описании было как отдельный документ. Топам в письме в кратком виде указывались причины и содержание документа.
Здравствуйте, я такой-то, работаю у вас там-то и тем-то, предлагаю провести трансформацию <(я не знаю чего ибо читать текст не реально) >. Это принесёт нам следующие бенефиты в тпкой-то срок: на языке денег перечисляете бенефиты. Это потребует столько-то вложений и столько-то времени. Сделаем силами нашей команды. Давайте встретимся и я расскажу подробнее
Орфографию и пунктуацию, все же, желательно подтянуть. Глаз режет.
Больше 1000 человек? А можно точнее? А то получается 3 ИТка на 7 рабочих(да и из них половина начальники) :-)
Вам дали задачу навести порядок в конкретном отделе, вы же вылезаете на уровень управления организацией пытаясь навести порядок вверхах. Вы правы, без порядка в целом, сложно строить идеальный порядок в конкретном. Но ровно эту сложность вам и следует решать. Product Owner, обладающие влиянием сменить вас на нового ИТшника одной эмоцией, вам не помогут. Отвечать за бардак - дураков нет. Начинайте с чего то лакального для вас, формализуйте описание своих сервисов, OLA, SLA. Классифицируйте Features, Stories. Выберите одну сквозную систему из трех ИС и попытайтесь перетащить все в нее. И уже на этом этапе вы увидите, что вам не тестировщика не хватает, а оператора сервис деск. Удачи! И старайтесь меньше текста использовать, лучше делайте слайды с картинками.
По вопросу о реакции топ-менеджмента.
На первых строках должен быть мотиватор читать дальше. С количеством потенциально зарабатываемых тугриков ($).
Глобально: Если нет выхода напрямую на собственника бизнеса, то надо договариваться (объединяться) с вышестоящим в пищевой цепочке компании (с тем же руководителем ИТ) и уже с использованием этого трамплина прыгать наверх. Не к абстрактным топам, а к конкретному и т.д.
Локально: Улучшить показатели вверенного отдела, параллельно вовлекая (принуждая) в улучшения смежные отделы.
По существу статьи: в дополнении к тексту оформить "картинки" было-будет с метриками типа срок/стоимость/качество.
Удачи!
Судя по пассажу про "разработчик на микросервисы" автор особо не понимает ни что такое разработка, ни что такое микросервисы.
"разработка микросервисной архитектуры" - это, как ни удивительно, задача архитектора, а не разработчика. Если у вас там монолит - ровесник мамонтов, то мало просто нанять условного сеньора-помидора и ждать, что он и архитектуру родит и сами сервисы напишет. Тут одни архитектурные утряски могут до года времени занять.
"Ведущий тестировщик" - тоже вызывает вопросы. Вам лид QA нужен, скилловый авто- или ручной тестер? Уверены, что одного "ведущего" будет достаточно? У меня на прошлом проекте над QA для приложения на 200к строк трудились 1 QA лид и команда из 3 автотестеров.
Простите, но можно человеческим языком? Я не имею ввиду, что всё это нужно сократить и упростить, что должна быть чёткая связь между пунктами, и обьяснение что, где, как и зачем автор рассуждает
Плюс, очень много демагогии. Но кому как
Спасибо всем откликнувшимся (в том числе в личке).
Хочу ответить на ваши комменты одним сообщением:
На счет способа изложения. Сложно предугадать как воспримят тот или иной контент разные люди. Не зная на сколько они погружены в терминологию и проблемы ИТ, я старался объяснить как можно понятнее. Это порождает большой объём. К тому же, указанное нельзя было оцифровать (предоставить показатели) по всему ИТ (по крайне мере в имеющееся время).
В письме топам, в кратком виде, указывались причины обращения и содержание приложенного документа. Всё остальное шло вложением.
Оценка трансформации, план, ресурсы и т.п. не делались, т.к. не была понятна позиция руководства по изложенному. К тому же, трансформация затронуло бы весь ИТ, а такое в одиночку просчитать и спланировать в крупных компаниях маловероятно. Если бы руководство выразило заинтересованность, то дальше пошли бы уточнения и согласования.
В качестве примера приведу анекдот: Нанял муж детектива, т.к. подозревал жену в измене. Детектив предоставил отчёт, в котором было указано, что его супруга встречалась в квартире с незнакомым мужчиной: Наблюдение в окно показало, что они пили вино, танцевали, потом разделись, легли в кровать, закрыли шторки. Дальнейшее наблюдение было невозможно по объективным причинам. Муж прочитав отчёт сказал: ну как всегда, никаких доказательств.
Т.е., по моему мнению, кто заинтересован увидеть проблемы, увидел бы их и не остался в стороне.
Судить о предложенном составе отдела, без знания объёма работ поддерживаемых систем, и составов других отделов, затруднительно. Поэтому оставлю коммент без ответа.
О связи пунктов. Я пытался представить их так:
текущая ситуация в отделе
выводы
предложения по отделу
предложения по всему ИТ
На счет демагогии. Демагогия, в моём понимании, должна базироваться на логических ошибках в тексте/речи. Какие логические ошибки здесь?
Вариант пути трансформации ИТ в компании