Управление программными проектами: процессы, инструменты, методики

Trello

Удобная система управления проектами, простой и универсальный онлайн-инструмент в виде  веб-версии trello.com, мобильных приложений для Android и IOS, а также расширения для браузера Google Chrome. О Trello написано много (в том числе и на страницах нашего журнала), приложение остается самым удобным и легковесным решением для командной работы и в 2019 году. Сервис реализован по принципу канбан-доски: пользователь создает доску, на ней списки, внутри которых карточки.

Канбан-доска — принцип представления задач и управления проектом. Идея в том, что задачи представляются карточками на доске, расположенными в несколько столбцов, означающих этапы разработки (производства). В процессе разработки карточка перемещается из столбца в столбец, пока не достигнет последнего, списка “Готово”. Таким образом, визуально контролируется равномерное распределение нагрузки на каждом этапе.

Плюсы Trello

Простота, универсальность и многофункциональность. За это его любят профессиональные руководители проектов и продакт-менеджеры (если хотите примкнуть к таким – посмотрите неплохие курсы от Skillbox по этой тематике).

• понятный интерфейс;
• доски и списки настраиваются под проект в любой сфере;
• карточкам можно назначать ответственных;
• к карточке прикрепляются ссылки, изображения, файлы, чеклисты, пользователи могут комментировать карточку;
• Web-clipper позволяет создавать карточку в Trello, подтягивая в нее название веб-страницы, ссылку и иллюстрацию текущего сайта;
• доступно подключение к Trello сторонних сервисов и надстроек: календарь, Gmail, Google.Drive, Dropbox и другие — о многих сервисах автоматизации мы писали в другой нашей статье;
• в бесплатной версии нет ограничений по количеству пользователей и персональных досок.

Web Clipper — расширение для браузера, которое сохраняет содержимое сайтов напрямую в сервис, которому принадлежит, не покидая страницу сайта. Может сохранять текст, адрес сайта, иллюстрации.

Недостатки Trello

В этой системе управления проектами по умолчанию нет диаграммы Ганта, невозможно оценить прогресс во времени. Это решается подключением плагина Planyway Team Planner (подробнее все в той же статье про Trello) или календаря;

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

Диаграмма Ганта — диаграмма в виде полос, расположенных на оси времени. Используется для планирования проектов и графика работ. Каждая строка диаграммы это этап работ, который начинается, когда заканчивается этап на строке выше. Визуально диаграмма похожа на лестницу.

Тарифы Trello

Бесплатный

• неограниченное количество персональных досок, списков и карточек в доске;
• подключение 1 плагина к доске;
• вложение в карточку — до 10Мб
• 10 групповых досок.

Business Class — $9.99 в месяц за 1 пользователя

• неограниченное количество персональных досок, списков и карточек в доске;
• неограниченное количество плагинов к доске;
• вложение в карточку — до 250Мб;
• неограниченное количество групповых досок;
• дополнительный уровень доступа для пользователей без возможности редактировать, только комментировать;
• коллекции досок;

Enterprise — $20.83 в месяц за 1 пользователя

• неограниченное количество персональных досок, списков и карточек в доске;
• неограниченное количество плагинов к доске;
• вложение в карточку — до 250Мб;
• неограниченное количество групповых досок;
• дополнительный уровень доступа для пользователей без возможности редактировать, только комментировать;
• коллекции досок;
• дополнительные возможности администрирования досок, прав доступа и индивидуальная адаптация сотрудников. Легкость в освоении сразу же снискала славу у легкообучаемых представителей поколения Z – мы уже писали об этом в нашей статье о поколении Z.

Ключевые факторы

Управление

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

Регулирование

Программа должна поддерживать видение верхнего уровня, цели и задачи.

Уверенность

Проверьте и утвердите программу, убедитесь в следовании стандартам и в соответствии видению.

Руководство

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

Интеграция

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

Финансы

Выследите основные издержки вместе с административными издержками программы.

Инфраструктура

Распределение ресурсов влияет на издержки и на успех программы. Инфраструктура должна покрывать офисы, контроль версий и ИТ.

Планирование

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

Улучшения

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

Как мы первыми в мире роботизируем кормоуборочные комбайны

Недавно мой коллега рассказал как мы роботизируем зерноуборочные комбайны и чему научились за этот сезон.
Начинается уборка кормовых культур и мы активно осваиваем кормоуборочную технику. 
Кормоуборочный комбайн – технически более сложная и мощная машина. В связке с ним идут сразу несколько транспортных средств для сбора урожая (трактора с прицепом, грузовики, силосовозы). К работе на такой технике допускаются только опытные механизаторы, у которых за спиной несколько лет работы.
Работа на комбайне во время уборки кормовой кукурузы похожа на езду в машине в густом тумане, только вместо тумана на протяжении всего пути высокая зеленая стена из растений, из которой может выскочить кабан, столб или человек. Перемолов человека (история есть в моей прошлой статье), комбайнеры седеют и больше не могут работать. Кроме этого, в этом «зеленом тумане» надо суметь не врезаться в рядом едущий силосовоз, следить за точностью загрузки силоса с хоботом длиной до 7 метров, из которого вылетает по 50-60 кг силоса в секунду, и равномерно заполнять фургон, чтобы он не гонял полупустым туда сюда.
Фактически один комбайнёр работает за троих, следит за процессом уборки кукурузы (одно рабочее место), ведёт технику (второе рабочее место), загружает силосовоз (третье рабочее место). В итоге что-то страдает. Если плохо вести, можно сломать дорогую технику (минимальная цена кормоуборочного комбайна 16 млн рублей, есть модели и по 50 миллионов), поэтому обычно ухудшается качество уборки и загрузки.
Большую часть работы мы автоматизируем, сейчас расскажу какие сложности мы преодолеваем и что делаем.

Спецификация СУИБ в ДОУ организации: какие реалии?

Из песочницы

Аннотация

В статье приводится описание спецификации и применения системы управления информационной безопасности на базе документационного обеспечения. Далее рассматривается:

1. Разработка и проектирование документационного обеспечения управления в системе информационной безопасности организации, в том числе программно-аппаратной реализации и ее спецификации.
2. Сторона унифицированных и специализированных характеристик управления структурой организации для внедрения в промышленную эксплуатацию приведенного формата решения.
3. Формат применительности представленного решения на действующей организационно-структурной организации, на базе методик проектной деятельности организации.
4. Формирование документационного обеспечения управления, которое базируется на системе управления информационной безопасности организации. Где данная система представляет из себя образчик требований для обеспечения целостности, доступности и конфиденциальности информации, которая обрабатывается посредством документационного обеспечения управления и непосредственно функционирующая в системе управления информационной безопасности.
5. Ликвидность организации согласно документационного обеспечения управления организации со стороны системы управления информационной безопасности организации.
6. Формат управления документационным обеспечением управления и распределения уровней доступа к категорированию данной информации, со стороны потокового документооборота организации, в том числе на базе локальных инструкций организаций.
7. Типовые формы для проведения оптимизации управления документационного обеспечения управления и системы информационной безопасности организации.

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

Пилотирование гибридных проектов

В гибридном методе используется классический метод декомпозиции работ на более мелкие управляемые компоненты. Это нужно для построения иерархической структуры работ проекта — ИСР (Work Breakdown Structure, WBS). Когда в проекте используется несколько направлений работ, каждое из которых представлено отдельной ветвью ИСР, одна ветвь (разработка программного обеспечения) может быть выполнена по Agile, а другие (поставка оборудования, развертывание локальных сетей, обучение конечных пользователей продукта) — по «водопадной» модели. Метод водопада используется для того, чтобы определить путь от требований заказчика и спецификаций до тестирования и окончательного выпуска продукта. При этом каждый компонент проекта подробно разрабатывается с помощью гибкого метода управления проектами.

WBS используется для планирования высокоуровневой дорожной карты проекта, а Agile — для разработки, уточнения и выпуска каждого 
компонента
 и подкомпонента продукта.

Мониторинг производственного оборудования: как с этим дела в России

Recovery Mode

Привет, Хабр! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.
Базовая проблема следующая. Вот вы производите установку для крекинга нефти, либо станок для машиностроения, либо какое-то другое устройство для завода. Как правило, продажа сама по себе крайне редко возможна: обычно это контракт на поставку и обслуживание. То есть вы гарантируете, что железяка будет работать лет 10 без перебоев, а за перебои отвечаете либо финансово, либо обеспечиваете жёсткие SLA, либо что-то подобное.
По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.
Установка мониторинга требует модификации железа устройством передачи данных, самой передачи, какого-то озера данных для их накопления, разбора протоколов и среды обработки с возможностью всё посмотреть и сопоставить. Ну и с этим всем есть нюансы.

Классификация проектов

Модель и параметры процесса производства ПО в значительной мере зависит от типа проекта. У каждой команды есть свои заказчики, с которыми сложились те или иные отношения.

«Свой» заказчик

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

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

Продукт под заказ

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

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

Тиражируемый продукт

Ситуация, при которой команда разработчиков либо вообще не имеет конкретных заказчиков («коробочный продукт»), либо довольно значительное количество заказчиков на один и тот же продукт. Основные характеристики такого типа проекта:

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

Аутсорсинг

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

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

Зачем проекту менеджер?

Цель нашли, что теперь? Тут начинается самое интересное для менеджера-новичка. Нужно собрать все силы в кучу, успокоиться, осмотреться и начать планировать проект.

Источник.

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

Руководитель проекта — не тот, кто делает, что написано в ТЗ, а тот, кто помогает определить проблему, понять, что работа идет корректно. Следит за тем, чтобы все понимали процесс и задачи правильно.

Здесь нет понятий «мы» и «они» — есть одна команда. Она вместе проигрывает или выигрывает. А хороший руководитель проекта должен сыграть роль связующего звена между командой и заказчиком. То есть из двух разных миров создать один.

Антон Сержантов,

agile-коуч

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

Важный навык для менеджера проекта — умение планировать: рисовать у себя в голове картину того, как и что должно быть. Нужно уметь сформулировать правила игры и донести их до команды.

Владимир Завертайлов,

руководитель scrum-студии «Сибирикс»

Цель управления проектом и успешность проекта

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

Группы оценок успешности:

• Ориентированные на контракт с жесткой фиксацией требований и минимизацией изменений в ходе проекта, например традиционные методологии, в том числе PMBOK: «проект успешен, если выполнен согласно утвержденным критериям: объёму, сроку, качеству». То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем (вне зависимости от того, являлся ли он юридическим документом в случае внешних проектов или определялся как-то иначе в случае внутренних проектов). При этом оценка успешности единая как для заказчика так и для исполнителя.
• Ориентированные на удовлетворенность заказчика с гибким управлением требованиями, например гибкие методологии SCRUM: «проект успешен, если заказчик удовлетворен»
• Ориентированные на длительное взаимодействие с Заказчиком: управление программами, направленное на длительное взаимодействие, а не на один проект/контракт. Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия.
• Сбалансированные, например PRINCE2: «проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости». Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии технологий. Оценка успешности может различаться с точки зрения бизнеса, пользователя и исполнителя. Такие методики оценки чаще используются для внутренних проектов, когда заказчик и исполнитель находятся в одной организации.

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

В целом можно определить цель управления проектами следующим образом:

«Целью управления проектом(-ами) является достижение заранее определенных целей при заранее известных ограничениях и целесообразном использовании возможностей, реагировании на риски.»

Даже при достижении поставленных целей и целесообразности изменений, проект может не соответствовать ожиданиям заинтересованных сторон. В проектах с высоким уровнем изменений требуется управление ожиданиями.

«Другой» менеджмент или почему бывает сложно общаться с людьми на работе

Недавно сменил очередное место работы, я программист, Team Lead, PM, BA, Data Analytic, HR, QA, CTO, продюсер и психолог (последнее и по образованию, и по факту).

Не так давно я очень заинтересовался конфликтами в рабочем коллективе, а точнее – от куда они берутся и что с ними можно делать, чтобы они не мешали работе, а или даже наоборот – помогали. Больше всего бросилось в глаза то, что люди никогда не говорят о том, что они действительно хотят сказать, даже когда переходят на повышенные тона.

Приведу пример. Если вы как-то связаны с it, то, наверное, вам удавалось слышать такие фразы как:

• Я уже 3 года, тут работаю, а он только пришёл
• Front End ничего не смыслит в Back End
• Менеджеры надоели со своими бесполезными митингами
• Дизайнеру это просто вправо подвинуть, а нам переделывать неделю

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

Для планирования задач

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

Trello — пожалуй, самый известный сервис для организации задач в виде рабочих досок. Базовая часть сервиса бесплатная, оплачиваются только расширения. Есть возможность добавлять чек-листы и выставлять приоритеты. Может синхронизироваться со Slack, GitHub, Salesforce, Evernote, Google Drive. Отлично работает в Kanban-проектах.

MeisterTask — почти полностью повторяет функционал Trello. Отличительная особенность — интеграция с упомянутым выше MindMeister, а заодно — со Slack, GitHub, Zendesk.

Jira — вообще-то это система отслеживания ошибок, которая задумывалась как инструмент для организации взаимодействия с пользователями. Но многие применяют Jira для управления проектами (мы в том числе). Идеально подходит для работы по Scrum. Позволяет планировать спринты и проекты в целом, делегировать задачи и собирать их в бэклог, указывать приоритеты и отслеживать дедлайны.

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

Что такое проектный менеджмент?

Управление проектами, проектный менеджмент, project management, РМ — названия процесса достижения той или конкретной цели в заданных рамках (временных, бюджетных и пр.). При этом в понятие РМ входит также набор инструментов, методик, навыков и техник, который применяется для достижения цели и может варьироваться в зависимости от изменяющихся условий, в которых ведется работа (появления как рисков, так и возможностей).

Немного истории развития стандартов управления проектами

, что проектный менеджмент в привычном нам понимании появился в 1950-е годы ХХ века. Но есть и исследователи, которые считают, что уже при строительстве пирамид Гизы использовали подход, напоминающий РМ (за возведение каждой грани отвечал отдельный человек).

Tria

Типовые конфигурации — бесплатно

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

Сравнение с 1С или немного историиСистема Tria родилась не на пустом месте. Сначала разработчики занимались созданием нестандартных решений на базе 1С 7.7. В результате последовательных изысканий родился механизм хозяйственных операций. Сущность данного механизма состоит в том, что вся логика поведения документа содержится не в коде на языке программирования, а задается с помощью специального справочника Хозяйственные операции.

Как результат, получили следующие плюсы:

• Логику работы документов можно менять «на лету», при этом остальные пользователи продолжают работать в базе.
• Значительно упростился и ускорился процесс вноса изменений в конфигурацию, а следовательно, значительно снизилась стоимость сопровождения. То, что программист делает в 1С за день в ТРИА можно сделать за час.
• Значительно снизился уровень требований к настройщику/внедренцу ТРИА. Люди, не умеющие программировать, сами настраивали проводки, меняли коренным образом логику работы программы. Сместился акцент в требованиях к внедренцам: в первую очередь специалисты должны знать предметную область, понимать методологию работы, а уже затем быть специалистами в ТРИА.

Естественно, что Tria получилась идеологически похожа на 1С. Те же справочники иерархической структуры, документы, журналы документов, регистры. Пока нет плана счетов и периодических реквизитов – планируется со временем. По сути, перед вами нечто похожее на компоненту «Оперативный учет» или «торговля» в 1С . Здесь, конечно же, хотелось бы нарисовать сравнительную табличку, тем более что 1С знакома вдоль и поперек, но многие сочтут это как антирекламу. Поэтому ограничимся очень кратким резюме: в 1С можно сделать почти все, что хочет пользователь. Вопрос только времени, денег и хорошего специалиста. Наше ПО более ограничено по функциональности, но все, что можно сделать в Tria, делается значительно проще и быстрее, а значит и дешевле. При этом программирование требует значительно меньшей степени подготовки специалистов. Главное конкурентное преимущество – это значительное сокращение расходов на покупку, внедрение, доработки и IT поддержку вашего программного обеспечения. Конфигурации, предлагаемые в ТРИА, содержат весь опыт успешного ведения бизнеса наших клиентов. Они получают не только программу, но и постоянные рекомендации и предложения по увеличению прибыльности их компаний. Мы гордимся достижениями наших клиентов, что за 4 года использования ТРИА в Луганской области ни один из клиентов не прекратил свой бизнес, а наоборот, несмотря на кризис успешно развиваются.

Технические характеристики TriaДля нормальной работы Tria достаточно Pentium 150, 32 мегабайта оперативной памяти, 15 мегабайт дискового пространства. Чем больше размер базы данных и объемы вводимой информации, тем большей мощности требуется компьютер (на котором размещена БД). Платформа Tria является portable application — т.е. программой, не требующей инсталляции. Вы можете устанавливать программу простым копированием всей директории, носить свою бухгалтерию на флешке. На любом компьютере вы сможете выписывать документы или получать информацию об остатках. В качестве хранилища данных используется бесплатный SQL-сервер Firebird (существуют версии сервера как под Windows, так и под бесплатные операционные системы (Linux, FreeBSD)). Для однопользовательской работы по-умолчанию предлагается работа с embedded-версией сервера Firebird, которая не требует его отдельной установки и администрирования.

Более подробно о возможностях Firebird можно почитать здесь:

• www.ibphoenix.com – сайт производителя
• www.ibase.ru – сайт компании, принимавшей участие в разработке данного сервера. Содержит очень много полезной информации на русском языке.
• www.interbase-world.com, www.sql.ru – сайты, где можно пообщаться с программистами, эксплуатировавшими данный сервер.

Версия для печати