Комментарии 8
Больше проектирования, больше документации, проработки теории.
Все в статье ярко противоречит тезисам Agile-разработки. Мне кажется для waterfall важны полностью документированные устоявшиеся шаги и этапы. Хотелось бы почитать про scrum-waterfall методологию подробнее.
Кажется что сейчас нет того засилья софта, идей и новых программных продуктов. (Тот же product hunt и Appstore не блещут новыми идеями). Развитие программных продуктов уходило в blockchain, сейчас ушло в AI. Возможно из-за отсутствия развития и появляются подобные статьи — 25000 символов (посчитайте и проверьте) и ни одного слова о деле и работе, решениях .
Построение дизайн-системы, токенов, user-flow, изменения и взаимодействие с frontend'ом достаточно несложная задача. Вообще во всех процессах delivery вроде нет больших проблем. Хотелось бы услышать более сложные, необычные, инновационные вещи.
Спасибо за комментарий.
Как и указано в начале, статья носит "сугубо философский характер, некий взгляд на вещи, на то, каким путём имеет смысл идти в выстраивании рабочих процессов над продуктом". Это некое размышление о том, что нужно выстраивать "язык общения" между отделами ради достижения общей цели - качественного продукта, который бы не являлся статьёй расходов. Тут скорее про путь к зрелости команд и владельцев бизнеса, про то, как на наш взгляд было бы уместнее выстраивать рабочие процессы внутри команд. Оценку зрелости предлагает CMMI модель, но не предлагает решений. Мы, в свою очередь, хотим дать пищу для размышлений о том, что необходимо искать пути решения для построения таких процессов управления командами, вкупе с методологиями Srum и т.д., с помощью которых можно достичь более эффективных показателей производств. Того уровня зрелости, при котором it-продукт будет частью бизнеса, что является инструментом на рынке, а не статьёй расходов.
В связи с тем, что у нас не хватает компетенций по всем направлениям, чтобы вывести общую формулу, мы пошли по пути некой идеи, философии и личного взгляда на подобные вещи, которые кто-то разделит, раскритикует, дав в свою очередь пищу для размышлений нам или дополнит своими компетенциями, переосмыслит со своей точки зрения.
В принципе, эта статья является вводной как раз для более конкретных статей.
Следующая статья выйдет в ближайшие дни. Она будет посвящена критике атомарной дизайн-системы, где мы предложим свой взгляд на вещи, более конкретный и обоснованный.
В тексте как-то очень вольно используется термин "процесс". Фразы типа " проектирование процессов в зарождающемся продукте" вызывают недоумение. Начните с Глоссария используемых терминов.
Спасибо за комментарий.
Справедливое замечание. Но поскольку эта статья носит скорее философский характер, как некое размышление о производственных процессах, мы не углублялись в Голоссарий.
В следующей статье мы подвергнем критике атомарную дизайн-систему и дадим свои термины и определения. Там всё более конкретно, поскольку вторая часть ближе к конкретике и практике, в силу имеющегося опыта и экспертизы.
На начальных этапах формирования программных обеспечений периода90-ых, 2000-ых годов, подход к проектированию программ был условным,в большей степени определялся самими разработчиками.
Хорошее начинание. Но некоторые утверждения, как выше, базируются, в большей степени, на персональном опыте. Если вы бы попали в ИТ из инженерной среды с реальным опытом проектирования продуктов, производств и комплексов, то взгляд был бы совсем другой.
Спасибо за комментарий
"Но некоторые утверждения, как выше, базируются, в большей степени, на персональном опыте" - это верно. Именно привносим свой взгляд на вещи. Возможно, кто-то найдёт в этом свою правду и поможет развить курс.
Что конкретны вы подразумеваете под инженерной средой с реальным опытом проектирования продуктов, производств и комплексов?
Отделы автоматизации строились из инженеров производств. Т.е. ты учишься, например, на электротехе или энерготехе и уже варишься в предметной области. Программирование - это элемент автоматизации производства, т.е. ты подбираешь язык, стек технологий под задачу. И задачи ставятся соответствующие производству и теми же подходами и процессами производства со знанием реальных физических процессов. Например, курсовая "моделирование процесса плоского шлифования встречным ходом". Идешь в библиотеку посмотреть по этой теме, а так, оказывается никто не шлифует и идешь на производство спрашивать что и как и почему. Узнаешь, что, да, можно, но на встречном ходу из-за ударных нарузок низкую шероховатость достигнуть проблематично и тебе нужно это доказать своим моделированием. Язык себе сам выбираешь, в соответствии с поставленной задачей. Получается уже студентом ты представляешь что такое производство и когда приходишь на работу уже не нужно всем это объяснять и почему важно обеспечивать производственные процессы.
И на работе ты уже сам делаешь реальные продукты и если нужно, то формируешь реальность :). Например, нужно повысить производительность труда на отгрузке и оформлении документов на складах комплектующих. Вникаешь в процесс, психологию - в реальную жизнь склада. И понимаешь, что нужно передавать документы из управления на склад (репликация данных), за компьютеоом кладовщик находится считанные минуты и ему все эти мышки некогда брать в руки, поэтому только использование клавиатуры. Интерфейс адаптивный под конкретный склад, т.к. на одном важны одни поля ввода, а на другом - другие. На одном складе накладная из нескольких позиций, а на метизах десятки тысяч и только печатать его нужно сильно подождать - нужен скоростной принтер ($10000) или напиши драйвер на струйник под старую ОС, чтоб печатать быстрей. Т.е. инженер заточен под решение прикладной задачи, изобретения и внедрение.
Сейчас же приходится объяснять зачем нужны процессы, почему и как важно и нужно обеспечивать надежность, непрерывность, отзывчивость и т.д. продукта и производства в целом.
Проектирование процессов разработки IT продукта