- [<] Date created: 25-03-2024
- [b] Related content: [[Собеседование на практику]]
- [*] Tags: #internship
- Упор на построение системы управления проектами.
- Положение/регламент по проектному управлению. Как компания будет управлять проектами?
- От меня требуется прислать лучшие практики, изучить опыт.
- Подготовить формы документов, паспорт проекта, план-график проекта. Наполнение этих форм будет за руководителями.
- Документы по управлению рисками. Важная для компании часть.
- Строгий документ. Стоит включить две части: строгая и вариативная.
- Документ будет содержать определения проектных этапов: инициация, планирование, разработка (контроль и выявление отклонение. работа со стейкхолдерами), завершение.
- Насколько я понял: цель - стандартизация.
- Нужно включить порядок формирования команды и бюджетирования.
- Типы проектов (контрактов):
- Создание / развитие информационных систем
- Сопровождение информационных систем (тоже будут считать как проект и учитывать как проект)
- Проект эксплуатации информационных систем (больше про аналитику) - информационно аналитические материалы.
- Риски. Риски отличаются от проекта к проекту. Вотерфол лучше в высокоопасных и важных продуктах.
- Связаны ли между собой? Скорее всего разные продукты, связаны только финансами.
- Учесть культуру и ценности (взять с сайта).
- Учитывать структуру команд. Описать то, что есть сейчас. Это важно, но на дальнейших этапах!
- Общение с заказчиками. Тоже включить.
- В сбербанке не было внутри команд. Но был регламент проекта.
- Почему им нужен регламент? Какая цель? Какая проблема?
- Если плохая коммуникация с заказчиками - углубляться в тз. Если сроки, то больший упор на циклы разработки и ассесмент постоянный в течении выполнения проекта. Может с финансами проблема - тогда смотреть на хайринг и распределение ресурсов. Мб хотят культурную проблему решить.
- Почему приняли решение делать регламент? Какую проблему хотите решить? Все-таки для кого он нужен? Для новых сотрудников, для заказчиков, для руководства?
- Первая задача регламента - описать процессы as-is. Потом можно внедрять изменения.
- Можно сделать один большой регламент по принципу ПДД - для решения проблемных ситуаций, но не для людей. А можно сделать набор понятных инструкций.
- Как вариант - сделать общий документ-регламент, который будет включать в себя гиперссылки на конкретные регламенты.
- Единый регламент (или перечень регламентов) по хорошему должен включать:
- Контрольные карты. Показатели. Порядок действий при отклонениях.
- Порядок формирования/изменения майлстоунов.
- Порядок, способы сдачи демо. Порядок обработки обратной связи - очень важно (+ порядок коммуникации с заинтересованными сторонами).
- Указание на ответственных за каждый этап.
- Порядок шеринга знаний, документации, кода, костылей и хаков
- Порядок оценки задач. Иногда этот процесс может сильно затягивать разработку.
- Порядок ревью кода.
- Порядок заведения задач и багов в task tracker. Распределение приоритетов.
- Список используемых программ и систем.
- Перечень используемых тегов в системах.
- Порядок выдачи доступов и перечень людей с необходимыми доступами (читающий будет знать к кому идти за согласованием).
- Порядок и частота обязательных митов.
- Я бы дополнительно включил переработки: в каких случаях выходим кранчить, как долго, в каком режиме.
- Если команды сами распределяют ресурсы, то порядок найма сотрудников, выделения бюджета и т.д.
- Если есть культура компании, то стоит основные моменты закрепить в регламенте.
- Документы: Гант-чарт, план-график: либо по майлстоунам, либо по спринтам, контрольные карты, плюс паспорт отдельно взятого проекта (todo: описать)
- Я бы порекомендовал сделать жесткий регламент и порядок, написанные простыми словами. Заложить туда культуру.
- Указать порядок и способы тестирования и демонстрации продукта.
- Контрольные карты. Показатели. Отклонения. Порядок исправления отклонений. Ответственные за каждый этап.
- Нужно вписать порядок шеринга кода, знаний, документации.
- Порядок оценки задач.
- Порядок обновления регламента.
- Порядок коммуникации заинтересованных сторон.
- Указать порядок баг-репортов с описанием формата.
- Перечень используемых тегов в системах/сервисах.
- Возможно стоит сделать несколько регламентов, один основной и включить в него ссылки на другие регламенты.
- Вариант: написать просто, но не спасет в спорных ситуациях. Написать как ПДД на все случаи жизни, но непонятно. Придется делать поясняющие инструкции.
- Гант, описания спринтов и майлстоунов.
- Распределения ответственности между всеми сторонами разработки.
- Уровни доступов и порядки их выдачи. Человек должен видеть к кому "бежать", если нужно что-то сделать.
- Регламент постановки задач.
- Регламент оценки задач.
- Регламенты code-style, git flow.
- Порядок обязательных митингов.
- Освежить информацию о регламенте проекта в проектном управлении. Выписать, зачем оно нужно и какие проблемы решает.
- Узнать, почему компании обращаются к регалментам в разработке?
- Узнать, что должно быть строго регламентировано, а что не очень.
- Подумать, как может выглядеть порядок разработки. Постоянен ли бэклог. Как часто приходят правки? И тд. Сформировать этот список вопросов и подготовить на него примерные ответы.
- Изучить паспорта проектов.
- Решение собственных проблем компании!! Повторяющихся ошибок.
- Масштабирование компании.
- Шеринг знаний. Анбординг сотрудников.
- Прозрачность и контроль.
- https://developers.sber.ru/docs/ru/sberid/service/sla-legal - регламент СБЕРА
Добрый день! Я накидал небольшие заметки по регламенту, пока что без примеров документов - записал только основные моменты, которые возможно имеет смысл включить в регламент.
И самое основное, что я забыл спросить :) Подскажите, почему вы решили делать регламент? Какую проблему он призван решить?
Большой и сложный регламент позволит четко описать все процессы, но он не сможет быть ежедневным помощником для сотрудников. Это как ПДД - большой и сложный документ, написанный для юристов. Полезен тем, что в случае аварии точно понятно кто и что нарушил. Но в обычной жизни люди пользуются сборниками с картинками.
На основе своего опыта и опыта коллег (я поспрашивал сегодня у знакомых), крупные компании делают на внутреннем портале страницу, которая содержит гиперссылки на документы под каждый случай. В таком случае регламентов будет много, но они будут маленькими и полезными в обычной жизни (в том числе при онбординге новичков). Тогда будут отдельные регламенты оценки задач, ревью, найма и т.д.
Если идти по пути единого регламента, то я бы включил туда следующее:
- Контрольные карты. Показатели. Порядок действий при отклонениях.
- Порядок формирования/изменения майлстоунов.
- Порядок, способы сдачи демо. Порядок обработки обратной связи - очень важно (+ порядок коммуникации с заинтересованными сторонами).
- Указание на ответственных за каждый этап.
- Порядок шеринга знаний, документации, кода, костылей и хаков.
- Порядок оценки задач. Иногда этот процесс может сильно затягивать разработку.
- Порядок ревью кода.
- Порядок заведения задач и багов в task tracker. Распределение приоритетов.
- Список используемых программ и систем.
- Перечень используемых тегов в системах.
- Порядок выдачи доступов и перечень людей с необходимыми доступами (читающий будет знать к кому идти за согласованием).
- Порядок и частота обязательных митов.
- Я бы дополнительно включил переработки: в каких случаях выходим кранчить, как долго, в каком режиме.
- Если команды сами распределяют ресурсы, то порядок найма сотрудников, выделения бюджета и т.д.
- Если есть культура компании, то стоит основные моменты закрепить в регламенте.
- Документы: Гант-чарт, план-график: либо по майлстоунам, либо по спринтам, контрольные карты, плюс паспорт отдельно взятого проекта (опишу отдельно).