Comments 11
Знакомые боли) А как решать ? Я думаю только организационно, т.к. единый источник истины это лишь инструмент, а ИИ еще недостаточно могет. И да, это будет дорого.
Мне кажется ИТ это про поиск компромиссов между качеством и ценой
Да, про компромиссы - это бесспорно, этим любая инженерная специализация занимается. Но вот условно есть чертеж и вроде из него много чего можно понять при строительстве или в машиностроении (я там был, я видел :) ). И составление чертежей - это основа конструирования и взаимодействия с производством. А в ИТ - все больше на словах получается. Т.е. ИТ пока в состоянии, как строители до изобретения бумаги - палкой на песке чертят и тут же забывают:) И это не организационная проблема. И ее надо решать до включения в схему ИИ. Дальше да неросеточка ,RAG и т.д.
да, тоже задумывался о передаче в могучие руки ИИ сегодняшней работы с задачами. оценили-прослезились, размер БД одной из систем - 7Гб. причем чтобы реализовать функционал, необходимо прогонять через ИИ процентов 20 от БД, ~1.4Гб только данных. пока такие контексты ИИ не под силу. Но, несомненно, в ближайшем будущем, это ограничение будет преодолено
Вы верно подметили: системы нет. И это одна общая проблема, которая порождает перечисленные вами 5-ть (а так-же и многие другие). Однако в статье, вы описали разные проявления (относительно этапов создания продукта) однако не описали ключевую проблему… т.е. более развёрнуто мысль "системы нет".
Текст моей попытки описать ключевую проблему вышел за пределы комментария и опубликован в виде статьи.
Вы так и до методологии управления доберетесь . Например model driven engineering))
Или requirements engineering так в разработке принято называть целостное управление задачами ))
"Каждая несчастливая семья несчастлива по-своему..."
Тем не менее, всегда можно шевелится и какие-то инструментики придумывать по месту. Например:
1. Научить коллег говорить слово "нет". "Я не понимаю". "Я не хочу это делать". Наделать соотвествующих статусов в трекерах. Потом строить аналитику по таким статусам и что-то думать. Легализовать это "нет" и "не хочу", поощрять даже. Пробовать продуктовые механики в проектных командах, когда у людей появляется возможность поиграть в разные роли, сегодня on duty, а завтра галстук нацепил и пошел в presale на несколько часов, в промежутках инфру своими руками поболтил в части касающейся, white paper пописал, короче, разные способы расширения сознания и ответственности. Изничтожать все плохо работающие артефакты. Аналитик принес сторю на 100 листов, которую никто не будет читать? Нарисовал ER, которая не будет иметь никакого отношения к конечному результату в коде? Значит, надо тормозить процессы, всех отправить делать ничего или играть на плойке. Даже на самом горящем проекте намертво остановить неправильную активность дешевле, чем ее продолжать.
Вообще, сложно ставить диагноз по фоторгафии, но "каждый думает о своем" - типично для проектного подхода. И тут надо думать в первую очередь не об инструментах, первичны люди;
2. Уменьшить поверхность всего. Меньше артефактов. Меньше диаграмм. Меньше страниц. Меньше всего. Если можно вместо кучи макулатуры быстро соорудить "живой" PoC, который всем позволит синхронизировать понимание - отлично же. Вводить культуру быстрого прототипирования. Увеличение ответственности для участника процесса, не "я закрыл за 3 месяца 33 тикета", а "я прекрасно провел лето, сделал А, это устранило наши боли B и C, а еще коллеги-смежники порадовались и внедрили и импакт просто офигительный, я доволен, все довольны";
3. Тут даже непонятно, а боль-то конкретно в чем? Звучит как "линейный менеджмент творит дичь, потому что [нужное подстваить]". Успокоить линейных. Подровнять топов, воткнуть нужные срочные метрики, чтобы у них ожидания начали сходиться с реальностью. Тут, опять же, есть куча разных треков в разных контекстах, например, разработчик свои тесты пишет для себя, тестировщик проверяет соотвествие продукта некоторым формальным требованиям и это все ортогональные штуки и т.д.
4. См. п. 2. Если коммуникации сложны - упростить. Уменьшить объем и количество ненужных артефактов, приоритезировать. Запретить людям делать ненужное. Научить задавать всех вопросы "Зачем это надо делать?", "Почему это надо делать именно так?" etc. Легализовать и поощрять подобные вопросы. Выстроить правильные вертикали, чтобы не только разработка могла с бизнесом разговаривать, да хоть поддержка, если у нее есть вопрос "какого хрена?" и нет внятного ответа. Опять же, выглядит как конфликт проект/продукт, смотреть надо для начала сюда. И, опять же, решают не инструменты и методологии, а люди, фокус всегда должен быть в первую очередь не на роботов, а на людей, иначе будет только хуже;
5. Тех. долг - штука неприятная. Но техническая и управляемая. Если он растет - проблемы в управленческой плоскости. Бизнес не получает правильную обратную связь, менеджмент не справляется с ресурсными задачами, неправильные процессы эскалации, неправильная инженерная культура, нет привычки выкидывать плохо написанный код, миллион других причин. Они все решааемы, если понять в чем конкретно проблема. Можно хоть каждый второй-третий спринт посвящать устранению, если уж так наболело.
В целом, любой инструмент или методология - сильно вторичен. Первична команда, контекст команды, взаимоотношения между людьми внутри и снаружи. Серебряной пули все равно не будет, а просто аккуратное изменение процессов и микроклимата может дать прирост к продуктивности на порядок. Казалось бы на ровном месте. Как-то так.
Но главный мой пойнт: перед тем как пробовать очередной способ выковать людям счастье на их головах, надо научится для начала хотя бы просто тормозить проблемные процессы. Под корень. Это уже дает кучу счастья практически бесплатно.
и вот, вы, от сохи, добрались, наконец, до сути.
методика разработки. точнее вам нужна методология, которая позволяет построить свою методику, свой подход на каждом проекте. в зависимости от его тяжести, объема, сложности, и опыта и состава команды.
если хотите совет, то найдите RUP 6. Rational Unified Process v6. именно 6й версии, последней, которую выпустила компания Rational перед тем как её купила IBM.
в 7й версии эффективные манагеры голубого гиганта испоганили всё, и например из "лучших практик разработки", понятных и четко обоснованных, сделали непотребство вида "принципы бизнес ориентированной разработки", направленные видимо на повышение продаж, и с техническим качеством вообще никак не связанные. говорю как "сертифицированный специалист по RUP v7". я тогда немного затянул с подготовкой, и не успел сдать сертификацию на 6ю версию. то что я увидел в 7й меня "немного удивило".
ну и вот. методология. масштабируемый процесс, шведский стол элементов, из которых вы , понимая принципы, строите подходящий процесс разработки , на каждом конкретном проекте.
именно так, как надо тут и сейчас: от записанных на коленке FTR до тяжёлых спецификаций.
ещё хорошо поможет переход от постановки требований в формате долженствования ("система должна делать делать такую то функцию, после нажатия, и выводить....") к повествовательному стилю юзкейзов ("прецедентов использования") пользователь нажимает кнопку, система выводит это, и запускает фоновую функцию...").
к трассируемости и понятности контекста и сути - сильно поможет принцип "usecase driven development" . всё вокруг прецедентов.
концепция постепенно развивающихся и детализируются артефактов поможет делать и понимать ровно то, что что надо сейчас. не перегружаться написанием документации, а детализировать прецеденты там и когда надо. у нас был проект 2.5 года, (2 последовательных госконтракта), и у нас часть прецедентов до самого конца так и остались в форме "бриф-дескрипшена". потому что всем и так всё было понятно. а 4 или 5 прецедентов, из трёх десятков, и были прописаны подробнейшим образом, по шагам, с приложением алгоритмов обработки записей в бд).
понимание "компонентно ориентированной разработки" поможет не участвовать в холиваре микросервисы против монолита, а правильно выделять в микросервисы то что само выделяется и оставлять в маленьких монолитных сборках то, что не требуется пока выделять, или что эффективнее работает в межпроцессном взаимодействии и общей памяти. ( и никакой распиаренный DDD вам не потребуется, имхо, хотя и изучите его для кругозора. "всё говорят", "в нем что то есть", но и про инжектирование зависимостей так тоже говорили, как о какой-то "высшей сакральности", а я смотрю на это как на ещё одну обычную фабрику классов и подстановку реализации в рантайме. в общем ничего ни сакрального, ни достойного кипяткопИсания нет - простое частное решение, если конечно, вы понимаете компонентно-ориентированной подход и фабрику классов. )
ещё почитайте для общего развития "проектно ориентированное управление" Дж.Родни Тернера.
тоже плохо представляю, где вы её сейчас возьмёте, но это единственная книга по управлению проектами которую я нашел, где где внятно описано "управление по вехам" и "планирование набегающей волной". поможет понять взгляд теории управления проектами на интерационную разработку. и эта книга, имхо, как мифический человекомесяц Брукса - нестареющая классика. ну разве что её не переиздают.
за сим, доброго вам дня и хороших поисков. как найдёте решение, скажите. самим не на всех проектах удается выстроить всё как надо ) до сих пор, да. но теория сильно помогает. как говорится чем смог, тем помог. ))
Неконсистентность системы может исправить только человек. Можно начать хотя бы с помощи ему, а где эта неконсистентность находится. В гите настройка true, а на хосте false, выяснять простейшие противоречия.
Дальше суммаризация, "а как у нас дела вот с этим". Обойти таски, репы, ответить на вопрос, что сделано, что нет
Кажется уже сегодня можно прикручивать AI
Таски есть, системы нет