Проектирование процессов разработки IT продукта
Это пища для размышления руководителям продукта и руководителям отделов разработки продукта, а так же, руководителям отделов, косвенно имеющих влияние на продукт. Для всех тех, кто имеет начальный уровень,в статье оставлены поясняющие определения для используемых терминов. Возможно, кто-то найдёт в этом смысл и сможет дополнить этот взгляд своим оп…
ChatGPT что ли текст писал? Одна вода. Хотя бы про CMMI и другие iso стандарты в сфере организации разработки упомянули. Вы думаете что до вашего рождения ничего не было, и после вашего рождения мир исчезнет? Особо прикололо что сначала дизайн и разработку делят в отдельные малозависимые команды, а затем борются с их немотивированностью на общее дело. Ничего не слышали про принципы создания оргструктуры компании - Матричная, дивизионная, плоская?
Перезалил комментарий, т.к. дополнил статью второй частью, для лучшего понимания того, что хотим сказать.
Здравствуйте. Спасибо за комментарий.
Мы тоже поднимаем вопрос о зрелости/незрелости команд, как и в CMMI. Да, мы не имеем обширных знаний и компетенций по различным стандартам и методологиям выстраивания производственных процессов. Как и указано в начале - статья является личным наблюдением, мнением о том, каким путём имеет смысл идти в выстраивании рабочих процессов над продуктом. Мы идём к тому, о чём вы упоминаете, возможно своим путём, учитывая менталитет и особенности обстоятельств рынка в России. Не все западные практики и теории безоговорочно подойдут на нашу действительность.
Хорошо если CMMI/iso стандарты применяют у нас и они работают, однако имея свой личный опыт — мы пишем о нём. Возможно, это подтолкнёт руководителей и управленцев на мысли думать в ту сторону, о которой говорим мы в данной статье. Так же, возможно, ваш комментарий с упоминанием CMMI и iso стандартов, поможет руководителям приблизиться к этой самой зрелости. Одно дело делаем.
Касательно «дизайн и разработку делят в отдельные малозависимые команды, а затем борются с их немотивированностью на общее дело», мы как раз говорим о том, что они должны быть немалозависимыми, при условии что команды всё равно разные, но делают одно дело. И привносить эту немалозависимость, мы предлагаем с помощью настройки « языков общения» между отделами, как минимум с помощью Scrum и кросс-функциональных знаний. К тому же мы будем показывать как приходить к этому на примере выстраивания языка общения у фронтов (между дизайнерами и верстальщиками), когда CMMI, на сколько я знаю не предлагает решения к достижению зрелости, а лишь квалифицирует уровень зрелости .
Зачастую отделы малозависимы и не имеют понимания «общего дела». Часто можно встретить, что сотрудники не заинтересованы в понимании «общего» процесса, сегодня они здесь - завтра на другом месте работы. Мы говорим как раз о зарождении и поддержке в общей заинтересованности развития продукта и отношений между отделами разработки. В любом случае это комплексная проблема, и решение не лежит в одной плоскости. Мы лишь рассуждаем и стараемся приобщить остальных к этому процессу.