Николай Медведев. Как ставить задачи разработчику. От требований до результата

Архетипы систем помогают увидеть структуру повторяющихся проблем и понять, почему привычное устранение симптомов не всегда приводит к устойчивому результату. На примере архетипа «Подмена проблемы» показываем, как возникают задержки, уравновешивающая и усиливающая обратная связь, побочные эффекты и зависимость от постоянного «тушения пожаров». Объясняем, как работает принцип рычага: как искать точку воздействия, сравнивать варианты решений и выбирать действия, которые дают эффект не только здесь и сейчас, но и в долгосрочной перспективе. Доклад в виде статьи: https://infostart.ru/pm/2704019/

Разбираем, как за пять лет удаленной работы изменились управленческие подходы в ИТ-проектах и какие риски чаще всего возникают у распределенных команд. Проверяем на данных, действительно ли перенос офлайн-подходов в удаленный формат снижает управляемость проектов, увеличивает количество коммуникационных ошибок и замедляет выявление проблем. Отдельно рассматриваем факапы удаленки: расхождения в понимании договоренностей, встречи без камер, сложности с заказчиками, которые по-прежнему предпочитают офлайн, а также влияние удаленного формата на трудозатраты, сроки, текучесть и ФОТ. Статья будет полезна руководителям проектов, тимлидам и руководителям направлений, которые работают с удаленными или распределенными командами. Доклад в виде статьи: https://infostart.ru/pm/2702441/

Разберем, почему классический бизнес-анализ, построенный вокруг сбора требований и написания ТЗ, все чаще не помогает попасть в реальную проблему бизнеса. На практических кейсах покажем, как переводить требования в гипотезы, проверять их через эксперименты, метрики и данные из системы, а не только через интервью с пользователями. Отдельно рассмотрим, как логи 1С и машинное обучение помогают находить скрытые факторы, убирать лишние функции и улучшать процессы без долгих обследований. Доклад в виде статьи: https://infostart.ru/pm/2702219/

Как превратить профессиональные сообщества в инструмент управления изменениями? Гильдии помогают не только объединять специалистов, но и продвигать инициативы снизу вверх, усиливать межкомандное взаимодействие и развивать сотрудников. Рассказываем, как сделать гильдии самоуправляемыми и рабочими, избежать формальностей и превратить их в движущую силу трансформации компании. Доклад в виде статьи: https://infostart.ru/pm/2701173/

Управление международными проектами создания решений на базе 1С:ERP требует особого подхода: задачи сложнее, рисков больше, а коммуникации значительно тяжелее, чем в российских проектах. Разберем ключевые особенности архитектурного сопровождение создания решений ERP, работы интернациональной проектной команды, а также сложности, возникающие при продаже решений в других странах. Покажем, почему привычные проектные методологии плохо применимы за рубежом, и какие преимущества дает подход управления международными проектами ERP специально разработанный компанией 1С. Рассмотрим трудности внедрения методологии и способы, позволяющие успешно их преодолеть. Доклад в виде статьи: https://infostart.ru/public/2699179/

Почему на проектах внедрения ERP-систем возникает разрыв между бизнесом и разработкой – и какую роль в его закрытии играет бизнес-аналитик? Покажем фреймворки, которые помогают точнее выявлять проблемы, проектировать пользовательские сценарии, приоритезировать требования, проверять гипотезы и снижать риски сложных внедрений 1С. Объясним, как CATWOE, CJM, GA, HADI, MECE, MoSCoW, SAFe, UC и ТРИЗ могут быть полезны аналитикам 1С не как догма, а как практические инструменты для работы с бизнес-задачами. Доклад в виде статьи: https://infostart.ru/pm/2697111/

Каким должно быть техническое задание, чтобы разработчик понял задачу так же, как аналитик, тестировщик и бизнес? Покажем, почему требованиям нужны обоснование, конкретные формулировки по SMART, единый командный контекст и визуальная опора в виде схем, макетов и глоссария. Объясним, как недосказанность, размытые формулировки и отсутствие коммуникации превращают даже хорошо оформленное ТЗ в источник ошибок. Отдельно поговорим о soft skills: регулярных встречах, синках, воркшопах и умении вовремя проговорить нюансы с исполнителями. Доклад в виде статьи: https://infostart.ru/pm/2696528/

Быстрый переход с иностранного ПО на российские решения редко бывает просто заменой системы – особенно когда речь идет о МСФО, ежемесячной отчетности и отключении от зарубежной инфраструктуры в жесткий срок. На примере проекта перехода с Oracle JD Edwards и Harmony reports на 1С разбираем проблемы, с которыми сталкивается команда: неполные данные, отсутствие доступа к исходной системе, скрытые доработки, накопленные ошибки учета и постоянный поток новых требований. Объясняем, почему кризисный подход не дает гарантий результата и чем полноценный переход отличается от установки нового программного обеспечения. Отдельно рассматриваем правильную методологию замещения: детальное обследование, стратегию перехода, методологическую подготовку и поэтапную автоматизацию. Доклад в виде статьи: https://infostart.ru/pm/2693629/

Разбираемся, когда бизнесу выгоднее использовать готовые решения, а когда действительно стоит инвестировать в разработку с нуля. Показываем, как тиражные продукты помогают быстрее запускать процессы, сокращать затраты и снижать нагрузку на IT-команды на примерах интеграций 1С с маркетплейсами, логистическими сервисами и другими инструментами. Объясняем, по каким критериям выбирать решения на маркетплейсах, зачем тестировать демоверсии и оценивать условия поддержки. Отдельно рассматриваем гибридный подход, который позволяет закрыть типовые задачи готовым продуктом, а уникальные бизнес-требования доработать под себя. Доклад в виде статьи: https://infostart.ru/pm/2692399/

Рассказываем, как использовать текст договора в качестве инструмента управления проектом: фиксировать ожидания, этапы работ, сценарии выполнения и возможные изменения. На примере проектов переноса данных 1С показываем, чем они отличаются от проектов внедрения, зачем нужна короткая анкета на старте и как декомпозиция помогает заранее «разложить проект на кирпичики». Объясняем, почему IT-проекты можно оценивать по аналогии со строительством – через понятные виды работ, объемы и нормировки, – а коммерческое предложение стоит делать достаточно подробным, чтобы к нему можно было вернуться при изменении сценария. Отдельно разбираем, как повторяющиеся этапы и фиксация работ по периодам помогают гибко управлять объемом проекта, снижать риски для подрядчика и упрощать согласования на стороне заказчика. Доклад в виде статьи: https://infostart.ru/pm/2691856/