Управление проектами разработки и внедрения ПО на примере trackstudio

13.01.16

Бизнес-анализ

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

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

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

Рассмотрим, как это работает на практике:

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

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

В описании пишем текст технического задания.

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

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

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

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

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

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

После оценки бюджета задача попадает к заказчику для утверждения бюджета (или отклонения)

Если бюджет утвержден, ТЗ может уточниться и переводится в разработку.

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

После завершения кодирования, задача уходит тестировщику, после, на тестирование заказчику.

Задачу можно оправить на доработку разработчику.

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

https://youtu.be/cBVRP1PmiYI

См. также

Бухгалтер vs ERP

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

15.05.2024    3505    0    TanyaRi    65    

25

Как мы оптимизировали процессы внедрения 1С: проектная методология КРОК

Внедрение изменений Бесплатно (free)

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

15.05.2024    4848    0    cesar    15    

47

Радио "Аналитик", 19 выпуск 2 сезона. Про Domain-Driven Design с Иннокентием Бодровым

Проектирование Анализ предметной области Бесплатно (free)

В девятнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, как и для чего применяют DDD, и почему аналитиком важно знать об этом подходе.

13.05.2024    370    0    Radio_Analyst    0    

3

Профессиональное мировоззрение учетного специалиста (ч.3). Бухгалтерская реальность (AR) как научная модель хозяйственной реальности (ER)

Анализ предметной области Бесплатно (free)

В этой части статьи обсуждается идея о том, что бухгалтерская реальность (AR) строится как научная (математическая) модель хозяйственной реальности (ER), а также рассмотрены общие принципы построения научных моделей.

03.05.2024    799    0    Polav62    9    

3

Переход на современные ERP-решения «1С» – дорожная карта, кейсы, рекомендации

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Статья об основных зонах внимания и часто допускаемых ошибках при внедрении современных ERP-систем – «1С:ERP Управление предприятием» и «1С:ERP.Управление холдингом».

27.04.2024    1808    0    user893825    0    

17

Радио "Аналитик", 17 выпуск 2 сезона. Про модель Кеневин с Андреем Путиным

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    500    0    Radio_Analyst    0    

5

Исследование потребностей пользователей в заказной разработке

Анализ потребностей и поиск решений Бесплатно (free)

Расскажем о Customer Development (CustDev) в заказной разработке, методиках исследования и проверке гипотез при создании MVP. Восстановим справедливость в отношении CustDev: рассмотрим, что это такое, и поделимся практикой применения.

18.04.2024    511    0    tachenkov    0    

4

Профессиональное мировоззрение учетного специалиста (ч.2). Хозяйственная и бухгалтерская (виртуальная) реальности

Анализ предметной области Бесплатно (free)

В этой части статьи предложен вариант профессиональной мировоззренческой модели на основе пары взаимосвязанных реальностей – хозяйственной реальности и бухгалтерской (виртуальной) реальности.

09.04.2024    672    0    Polav62    0    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Franco 82 14.01.16 13:24 Сейчас в теме
1.Ни один проект не начинается без уточнений. Если у разработчика нет вопросов к заказчику, то это либо гениальная постановка задачи либо «гениальный» аналитик или разработчик. А это всегда не так.У вас же разработчик не общается напрямую с заказчиком. Он общается с аналитиком, у которого с десяток проектов.
2.То же самое касается тестировщика.
3.Куратор заказчика напрямую уточнить требования разработчику - конечно же, для аналитика, разработчика или тестировщика это усложнение - а это изменение требований и изменение времени и изменение суммы. Это никак не оговаривается в программе. В итоге если заказчик что-то забыл изначально - он получит уже не то, что желал. Я не оправдываю такую ситуацию - я просто говорю, что жизнь такая.
В итоге - фигня.
---
А можно разрабатывать так, чтобы куратор заказчика видел результат каждого действия? Все версии сохранялись? Всегда можно было бы подкореектировать разработку? Вернуться к какой-либо версии? Пересчитать время? Изменить бюджет? В любой момент получить уточнения? Все эти уточнения фиксировать? При необходимости найти нужное уточнение? Искать в других проектах схожие задачи и подобные решения, чтобы с'экономить время?
dabu-dabu; +1 Ответить
2. ETALON-A 8 14.01.16 17:30 Сейчас в теме
(1) Franco,
В видеообзоре показан самый простой пример, в реальности все сложней. Я специально не вдавался в комбинаторику вариантов. Конечно же менеджер проекта на начальном этапе уточняет все нюансы, а также в процессе все могут обмениваться комментами и вопросами.
Жизненный цикл требования менялся уже не один раз, с учетом возникающих изменений, будет меняться и дальше....потому что как только вы прекратили менять свои процессы - значит вы деградируете...
>>А можно разрабатывать так, чтобы куратор заказчика видел результат каждого действия? - они видят инфу по этапам, могут настроить себе уведомления на каждый "чих", но видят то, что положено по доступу. По практике 99% заказчикам это не надо... нужен конечный результат по задаче, а то и по циклу. Чтобы "приучить" заказчика вовремя согласовывать бюджет, и то проблема. Если он будет отслеживать всю "движуху" - жизни точно не хватит.
>>Все версии сохранялись? Всегда можно было бы подкореектировать разработку? Вернуться к какой-либо версии? - это реализовано не на уровне данного трекера, а на уровне хранилищ. Это реализовано у мелкософта, совмещение изменений и кода, но там ценник лицензий 14 т. евро в год.
>>Пересчитать время? - да
>>Изменить бюджет? - да
>>В любой момент получить уточнения? - да
>>Все эти уточнения фиксировать? - да
>>При необходимости найти нужное уточнение?- да
>>Искать в других проектах схожие задачи и подобные решения, чтобы с'экономить время? - так и и делается, есть специальна кнопка "похожие задачи"
Прикрепленные файлы:
3. Aleskey_K 35 20.01.16 08:30 Сейчас в теме
использовали трек, перешли на девпром. стало удобнее, но он очень тормозит. функционал не покрывает всех требований.
4. ETALON-A 8 20.01.16 12:05 Сейчас в теме
(3) Aleskey_K,
>>использовали трек, перешли на девпром. стало удобнее, но он очень тормозит. функционал не покрывает всех требований.
Логичный вопрос: в чем тогда удобство...?
Оставьте свое сообщение