Доклады с конференций Инфостарта для специалистов 1С
INFOSTART EVENT — это конференции сообщества 1С, которые мы проводим с 2012 года. За это время они стали крупнейшей площадкой для обмена опытом между профессионалами отрасли.
На наших конференциях выступают настоящие практики из ведущих компаний России и СНГ, а не бизнес-тренеры. Доклады отбираются голосованием сообщества, а качество контента контролируют независимые эксперты. Каждая конференция охватывает интересы разных ролей:
для программистов — разработки и архитектурные решения, новые технологии и инструменты,
для аналитиков — методологии, работа с требованиями, анализ данных, управление изменениями,
для руководителей проектов и ИТ-менеджеров — управление командами, рисками, проектами и продуктами,
для специалистов по ИБ и администрированию — практики защиты, эксплуатации и поддержки систем,
для HR и тимлидов — развитие команд, soft skills и современные управленческие подходы.
За годы существования INFOSTART EVENT накопился большой объём уникального контента для всех специальностей из мира 1С. Практически по всем докладам мы готовим подробные транскрибации: они позволяют узнать суть докладов в удобное время и внедрить лучшие практики в своей работе.
Все материалы БЕСПЛАТНЫЕ в открытом доступе и помогают специалистам находить решения, обмениваться опытом и двигать отрасль 1С вперёд.
над каждым докладом работает минимум 6 человек.
За много лет существования Infostart Event у нас накопилось большое количество качественного и уникального контента, и мы рады представить вам эти материалы!
В статье рассматриваются эвристические методы оценки прикладной архитектуры автоматизированных систем, позволяющие повысить обоснованность проектных решений и снизить риски при разработке. Показываем, как с их помощью можно сравнивать варианты архитектуры по нескольким критериям и выбирать оптимальные решения. На примерах объясняем методы многокритериальной экспертной оценки, включая метод анализа иерархий и метод комплексной оценки. Материал будет полезен архитекторам, аналитикам и руководителям проектов, которым важно принимать взвешенные решения при выборе архитектуры автоматизированных систем.
Когда в каждом подразделении внедряются свои продукты и сервисы, общий ИТ-ландшафт компании становится разрозненным и сложным. В такой среде проекты легко теряют управляемость и буксуют, даже если стратегия формально есть. Раньше это называли «лоскутной автоматизацией», а теперь мы столкнулись с «лоскутной цифровизацией» и даже «лоскутной цифровой трансформацией». Разберем, как отсутствие единой архитектурной политики, слабая связь между стратегией и ИТ-портфелем, конкурирующие продуктовые инициативы, наследие старых систем и отсутствие единой модели приводят к расхождению интересов ИТ, бизнеса и функций. И как мы на этом зарабатываем, помогая компаниям разбираться с последствиями такой фрагментации.
Зачем разработчику нужна оценка задач и почему она не должна превращаться в оценку «с потолка»? Учимся применять методику PERT: декомпозировать задачи, использовать трехточечную оценку и работать с неопределенностью через формулы и статистику. Разбираемся, какие риски надо учитывать, какие скрытые трудозатраты часто забывают и как повышать точность оценок через микротесты и личную статистику. В статье вы найдете практические рекомендации, которые помогают сделать процесс оценки прозрачным и управляемым.
Даже опытные разработчики регулярно промахиваются с оценками задач, и это не случайность, а системный сбой мышления. Когнитивные искажения, психология занижения и эффект «я думал быстрее» приводят к срывам сроков и постоянным «не учел». Разбираемся, как выстроить систему оценки, использовать статистику и практические методы, чтобы перестать попадать в ловушки иллюзий.
Разбираемся, как подхватывать проекты, которые зашли в тупик или были заморожены на предыдущих этапах, и возвращать их к жизни. Покажем, как провести аудит текущего состояния, работать с неинформативной или отсутствующей документацией и выстроить системную работу с требованиями. А также объясним, как наладить взаимодействие новой команды, понять, когда требуется замена людей на проекте, и перезапустить отношения с заказчиком. Все подходы основаны на практическом опыте реанимации ERP-проектов с последующим успешным вводом систем в эксплуатацию.
Даже самые успешные проекты не всегда проходят идеально: где-то мы выходим за рамки бюджета, где-то задерживаем сроки, а некоторые инициативы так и не доходят до запуска. Многие сложности связаны не с технической частью, а с человеческим фактором – в частности, с ролью куратора проекта. Этот человек может стать как двигателем успеха, так и источником большинства рисков. Недостаток вовлеченности, полномочий или времени, а порой просто равнодушие способны свести на нет усилия целой команды. Разбираемся, какие качества куратора влияют на успех проекта, и как заранее оценить возможные риски. Поговорим о том, что важно предусмотреть и о чем нужно помнить при выборе тактики управления проектом, когда лучше не начинать совсем, а когда куратор имеет все шансы стать нашей «правой рукой».
Погружаемся в практику оценки задач изнутри: разбираем, какие ограничения мешают давать точные прогнозы, и как с ними бороться. Статья содержит практические рекомендации для тех, кто хочет научиться оценивать задачи уверенно, честно и с пониманием.
Корректно формулировать предпосылки и цели проекта умеют немногие. Как показывает практика, с этим очень тяжело справляются функциональные заказчики. И даже для сотрудников, которые много лет занимаются проектами внедрения информационных систем, это не тривиальная задача. Расскажем о том, как проверить корректность целей, сформулировать предпосылки и правильно составить Устав проекта.
Для точной оценки проекта входящей информации часто недостаточно, но оценку нужно дать и потом за нее отвечать. О различных подходах к оценке проектов и многоуровневой схеме оценки проекта от пресейла до сдачи работ, расскажем в статье.
Часто на проекте внедрения нужно понять, сколько времени уйдет на ту или иную задачу. От правильности расчета зависит, успеет ли разработчик сделать задачу в оговоренные часы или будет перерабатывать по ночам, и останется ли заказчик доволен стоимостью и сроками. Расскажем о простой методике расчета трудоемкости задач, которая позволит добиться оптимальных оценок и укрепить лояльность заказчика.
Как планировать долгосрочные проекты так, чтобы к концу команда не выгорела, и что делать, чтобы верно оценить срок задачи? Об этом на конференции Infostart Event 2021 Post-Apocalypse рассказала руководитель проекта «Сторителлинг» в Альфа-Банке Юлия Буланова.
В предыдущей статье мы выяснили, что высокая степень неопределенности проектной среды не является основной причиной срыва сроков проекта . Причина заключается в нашей организации работ на проекте. Таким образом, нам нужно решение, которое бы изменило нашу работу и позволило устранить такие явления как Закон Паркинсона, студенческий синдром, потеря выигрыша времени и передача опозданий в цепи зависимых заданий. Решение должно минимизировать перепрыгивание от задания к заданию, при этом оценка длительности заданий не должна переводиться в разряд обязательств. Что собой представляет решение читаем далее...
Все, кто когда-либо работал в проектах, знают, как важна точность даваемых оценок длительности выполнения каждого задания. При этом, достаточно лишь одному заданию опоздать, чтобы поставить под угрозу выполнение сроков всего проекта. Стараясь подстраховать выполнение своих обязательств, мы закладываем в оценку длительности каждого задания изрядное количество резервов времени. Однако, как бы мы не старались, проекты все равно не завершаются в срок. И тому есть свои причины … четыре основные причины, почему проекты никогда не завершаются в срок.
Считается, что для планирования и принятия решений по проектам их нужно прогнозировать и оценивать. Александр Белов, генеральный директор и руководитель проектов ГК «Белов и партнеры», рассказывает, почему стоит отказаться от оценок.
