Управление проектами *

Привет! Меня зовут Павел Ахметчанов, я руководитель направления улучшения процессов разработки. В статье расскажу про часто используемые методики оценок задач и есть ли в них ошибки. Посмотрим, как правильно ставить вопросы при оценке. Узнаем, что собой представляет время решения задач, а это далеко не очевидная вещь. Попробуем изменить свое мышление и получим рецепт для определения времени решения задач. 

Если спросить любого начинающего исследователя этой темы «А зачем нам оценка?», он скажет, что постоянно задают вопрос «Когда вы выполните эту задачу?», на который и надо ответить с помощью этой оценки. А что, если сам вопрос задан неверно?

Проект это сложная история. Обычно это относительно сложное и длительное мероприятие, создать программный продукт и провести его через стадию активной разработки до первой реальной коммерческой эксплуатации. Лично я видел как этот путь, в среднем, занимал от 2 до 5 лет на проекте с большой командой разработчиков.

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

Под катом наблюдения и личные выводы почему это происходит.

В прошлой части мы разобрали:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

С этим багажом заканчиваем с теорией и переходим к практике. Теперь, когда мы знаем, что хорошо, а что плохо, необходимо понять, как этого добиться. Тут надо задать два вопроса с совершенно разными ответами:

1. Как не допустить появления связанной архитектуры и сразу сделать хорошо?

2. Как исправить уже связанную архитектуру?

В этой части постараюсь развернуто ответить именно на первый, оставив второй на десерт.

Все уже пошутили и запомнили что если в тексте — , то его писал ChatGPT. А если нет, то человек?

Эта статья - самый подробный гайд в рунете, как отличить текст, сгенерированный Gen AI от текста, написанного человеком и как самому, используя GenAI писать очеловеченный текст. Я разберу реальные приемы, маркеры, ошибки и вооружу вас важными знаниями

Как вы думаете, нужно ли архитектуру на вашем текущем проекте подвергнуть масштабному пересмотру и исправлению? Ставлю на то, что большинство читателей ответят положительно. И эта часть именно про это. В ней мы рассмотрим:

1. Когда сложившаяся архитектура подлежит масштабным изменениям.

2. Что не менее важно, когда лучше оставить, как есть.

3. Ключевые признаки проблем в архитектуре.

4. Основные способы исправления таких проблем.

Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:

1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;

2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;

3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;

4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.

Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:

1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.

2. Что маленькие команды работают буквально в разы эффективнее, чем большие.

3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.

Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».

Привет! Меня зовут Борис Пишванов, руковожу архитекторами решений в Альфа-Банке. В статье хочу поделиться историей нашей команды архитекторов решений, которая включает около 90 человек и занимается созданием и разработкой архитектуры IT-решений для бизнес-инициатив крупного банка. Уверен, многим из вас наша история покажется знакомой, а возможно, кому-то поможет избежать наших ошибок или найти вдохновение для позитивных изменений.

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

Главной проблемой была именно разрозненность и отсутствие общей системы. Мы постоянно «латали дыры», заново решали одни и те же задачи в разных контекстах, но не могли увидеть единую картину и двигаться в едином направлении.

Нужно было что-то менять на кардинально новое. Мы начали искать подход, который помог бы объединить отдельные инициативы в единую осмысленную систему. И здесь наше внимание привлёк подход Capabilities-Based Planning (CBP), про который мы узнали из TOGAF.

Так родилась простая, но, как оказалось, рабочая идея: «А давайте подойдём к нашей работе как к развитию бизнес-функции. Через capabilities»

Технические команды часто избегают лишней документации, но информация всё равно каким-то образом передаётся, сохраняется и развивается. В этой статье — попытка разобрать скрытые механизмы общения внутри инженерных команд: как выстраиваются негласные соглашения, каким образом рождаются "внутренние диалекты" и зачем вообще всё это, если есть JIRA, Confluence и куча других инструментов. Много примеров, блоков кода на разных языках и немного личного опыта.

Здесь могло быть долгое вступление о том, почему круто смотреть сериалы в оригинале. Но вы и так всё знаете. Давайте сразу к делу.

Если ваш английский - Intermediate и выше, но вы всё ещё не смотрели “Кремниевую долину” в оригинале, расскажу, кому и почему этот сериал - must-have:

Меня зовут Александр, я CTO компании AppFox. Мы более 10-ти лет занимаемся заказной разработкой и также имеем собственные продукты. 

Эту мысль‑статью я вынашивал более 6 месяцев. В разный промежуток времени, я то хотел ее оформить, то нет.

Почему нет? — Мне казалось, что это моя личная рефлексия. Все всё понимают без меня. Зачем писать то, что и так очевидно?

Почему да? — Чем чаще я возвращаюсь к этой рефлексии, тем чаще я думаю, что это не только моя личная проблема. Но и проблема большинства участников команд, открывающих новый путь внутри стандартных процессов.

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

Сфера проектирования вышла на новый уровень с появлением BIM-технологий. Помимо стандартных «коробочных»‎ решений, во многих САПР реализована возможность использования API для расширения базового функционала инструментов.

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

Основные цели автоматизации проектирования — это сокращение трудозатрат проектировщиков и улучшение качества финального продукта.

Внедрение автоматизации стало доступным, но как ее внедрять, чтобы она была поддерживаемой и расширяемой? Что делать, когда плагинов становится слишком много? А если проблемы качества кода и его структуры становятся актуальными? Если над разработкой таких плагинов теперь работает не один человек, а целая команда? И кто такой Октавиан?

Одна из причин этих сложностей ясна: при внедрении BIM нет общего видения, как должна выглядеть система целиком. Многие разработчики плагинов не обладают опытом разработки до того, как начинают их писать. Часто отсутствуют технически подкованные коллеги, которые смогут научить и спроектировать структуру «на берегу»‎. 

С такими проблемами мы и столкнулись в нашей команде проектной автоматизации ПИК — и пришли к созданию своего фреймворка ReactiveBIM, который уже несколько лет показывает себя с хорошей стороны. 

Чтобы не вводить в заблуждение: слово «Reactive»‎ не имеет отношения к реактивному программированию, а подчеркивает ускоренное погружение новых специалистов в разработку плагинов для автоматизации BIM-моделирования.

ReactiveBIM — это платформа с открытым кодом для разработки плагинов для CAD/BIM программного обеспечения. Эта платформа предлагает разработчикам надежную структуру проекта, внедрение зависимостей, легкую настройку, удобное ведение журналов, автоматизацию сборки пакетов и многое другое.

Хотим рассказать про наш опыт и про ReactiveBIM подробнее, а также спросить вас, читателей, мнение о нашей работе. Возможно, наш проект заинтересует вас, и вы захотите принять участие в развитии opensource продукта.

В статье будет рассматриваться только часть фреймворка для Revit, но функционал включает в себя также поддержку Autocad.

Приятного чтения!

Только мировые Best-Practice's. Примеры.

Делюсь опытом о процессе разработки программного обеспечения используя Agile, начиная со сбора требований и заканчивая развертыванием.

В прошлый раз мы обсуждали управление рисками в IT-разработке. В этот раз давайте поговорим о “мягких” навыках бизнес-аналитика, а именно о делегировании в контексте работы бизнес-аналитика в IT-разработке, Agile-проектах, нелинейного подчинения и взаимодействия и наших с вами откровенно завышенных ожиданиях от того, как влияет наша с вами работа на профессиональный и карьерный рост. Мы рассмотрим разные грани этого инструмента через модели планирования, лидерства, мотивации и обучения.

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

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

Думаю, большинство из вас понимают, в чем основные преимущества. Это: