Управление разработкой *

- А давайте добавим ещё фильтр…
- Хорошо бы выгрузку в Excel
- Вот бы ещё график и пуши — красиво же будет!

Проект набирает скорость. Только вот в каком направлении?

Согласно своду по управлению знаниями PMBoK существует 4-е ключевые плана, характеризующие любой проект, в том числе внедрение ERP-систем: график проекта, ресурсный план, план затрат и закупок. В литературе обычно описывают только построение плана-графика проекта с использованием методов критического пути и цепи, однако взаимосвязь с ресурсным планом и прочими планами обычно опускают. В работе [1] сделана попытка одновременного построения первых трех планов в виду их корреляции, способ базируется на бенчмаркинге этапов проекта и оценщике разработок. Однако вопрос оптимизации построенного ресурсного плана обсуждается лишь вскользь.

В данной работе мы выполним анализ примеров построения ресурсного плана в проектах внедрения ERP-систем, что позволит планировать человеческие ресурсы более точно и обеспечит более эффективное и качественное имплементирование программной системы. Для начала более подробно разберемся, как взаимосвязаны между собой три плана: проекта, ресурсный и затрат. Обычно план проекта ведется в разрезе задач, далее на него налагается ресурсный план, показывающий, какое число человеческих ресурсов требуется для выполнения активностей. Зная число и квалификацию ресурсов, а также их ставки, возможно рассчитать план по затратам. Таким образом все три плана связаны между собой и изменение одного из них непременно приводит к обновлению других. Наконец, построив ресурсный план, мы фактически формируем планы проекта и затрат.

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].

LLM позволяют генерировать рабочий код быстрее, чем когда-либо, но команды разработчиков не ускорились. Стоимость понимания, тестирования и доверия к коду выросла, а традиционные узкие места — код-ревью и координация — стали еще более критичными.

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

Для начала представлюсь — меня зовут Роман, я аналитик и проджект разработки информационных систем, в основном с веб‑интерфейсом. Занимаюсь этим делом давно, и понятно что сдавать проекты различной крупности приходилось неоднократно. Но рассказать хочется об одной недавней разработке, когда на этапе сдачи выплыло особенно много незапланированных изначально вещей, что сделало ее (сдачу) особенно длинной и болезненной. Надеюсь, что пытливый читатель возьмет этот опыт на вооружение и хотя бы продумает пути завершения проекта заранее.

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

В этой статье не будет примеров кода и конкретных архитектурных приёмов. Но если, читая книги и статьи по Domain Driven Design, вы недоумеваете «зачем это всё вообще», возможно, у меня есть для вас ответ. Правда, боюсь, что он вам не особо понравится.

Привет, Хабр! Чтобы не вводить никого в заблуждение, кратко перескажу, о чём пойдёт речь. Если тема будет вам близка или вы сталкивались с подобным, буду рад узнать ваше мнение и послушать советы.

Краткий пересказ:

Как я/мы в компании создаём процесс тестирования практически с нуля. Какие шаги предпринимались и как вообще получается в современном мире существовать без тестирования.

Вводные данные:

Я — QA, который работает в средней по размерам IT-фирме, которая, в свою очередь, является «дочкой» довольно крупной промышленной компании и обеспечивает поддержку и разработку внутренних систем. Когда я только пришёл, помимо меня был только один тестировщик на ~15 разработчиков. Ни о каком адекватном процессе тестирования речи и не шло.

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

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

Было принято решение взять нескольких тестировщиков, да не просто каких-то, а с навыками автоматизации, чтоб оно всё там как-то само.

Так я, собственно, и попал в команду — молодой и неопытный. На самом деле, не настолько всё было плохо: разработчики работали по TDD, так что unit-тестов хватало, и пайплайны отрабатывали автоматически. Да, не было тестирования как процесса, но ведь давным-давно, в далёкой-далёкой галактике, именно так и начиналось программирование.

Привет, Хабр!

Если ваши 1:1 — это «ну, поболтали и разошлись», а менторство выматывает сильнее, чем два продакшн‑инцидента подряд, значит что‑то не так. В этой статье рассмотрим эту проблему.

Артефакт, которому стоит уделить время в начале проекта, чтобы выстроить ясные приоритеты в разработке продукта, сэкономить бюджет и увеличить шансы на успешный релиз. Рассказываем, как работает карта влияний в цифровом продукте.

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

Вы узнаете:

Как благое намерение "усилить команду" превратилось в механизм самоуничтожения;

Почему пассивность квалифицированного специалиста опаснее открытого саботажа;

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

Этот текст - антидот против управленческой иллюзии. Если вы хоть раз чувствовали, что "процесс работает, а результат умирает" - вы уже в эпицентре.

Привет! Меня зовут Елена Тупикова, я академический руководитель программы онлайн-магистратуры «Управление IT-продуктами» от Яндекса и МФТИ. В этой статье я расскажу, чем занимается продакт-менеджер в IT и для чего ему нужно разбираться в базах данных, языках программирования и машинном обучении. А ещё дам список технических навыков, которые нужны продакт-менеджеру для работы в IT.

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

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

Разработчики фокусируются на промпт-инжиниринге, но настоящий прорыв — в контекст-инжиниринге. Это системный подход к подготовке данных для LLM.

AI-хайп накидывает новых терминов, в статье объясняем о чем тут речь.

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

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

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

Привет! Меня зовут Андрей, я технический директор в компании КЕДР Solutions. Мы занимаемся контрактной разработкой электроники и программного обеспечения. “Рисуем” платы и кодим уже больше 10 лет! 

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

Вы наверняка замечали, что в начале общения ИИ кажется очень толковым и понятнливым, правда почему спустя 10-20 сообщений начинает путаться, повторно совершить те же ошибки которые уже совершал или выдавать рассчеты с ошибками. Это не случайность, а следствие мироустройства. Давай разберемся почему это происходит и как именно ИИ все “помнит” и почему его память устроена иначе чем у человека.

Что делать, если через пару месяцев аутсорс-команда исчезнет, а проект с кодом, который вы видите впервые в жизни, целиком остаётся на вас? История и маленькие практические советы по выживанию от разработчика — для команд, которым предстоит забирать проект в условиях отсутствия документации, и для тех, кто внезапно оказался за это ответственным.

Лично мне нравится LLM как инструмент, усиливающий мои интеллектуальные возможности. Я использую его ежедневно — для поиска информации, для создания и перевода текстов, в качестве ассистента по подсчёту калорий и, само собой, для разработки приложений. Немного попрактиковавшись с генерацией pull request'ов через OpenAI Codex для модулей своего проекта TeqCMS, я пришёл к выводу, что в "грядущую эпоху вытеснения разработчиков моделями" настоящую ценность представляет вовсе не код и даже не проектная документация. Главный артефакт — это инструкции, настраивающие контекст для Агента, и история запросов, с помощью которых генерируется код.

Как часто оценка по задаче совпадает с реальными трудозатратами?

Умение точно оценить объём работ спасает от переработок, напряжённой обстановки на проекте, поддерживает доверительные отношения в команде и показывает вас с хорошей стороны перед заказчиком.

Но интуитивные и ставшие традиционными способы оценки задач дают низкую точность. Пора взять на вооружение другой способ, дающий 90+% точность в оценке.