Александр @Kettariecz
Системный инженер
Information
- Rating
- Does not participate
- Location
- Екатеринбург, Свердловская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Systems Analyst, Software Architect
Lead
SQL
ArchiMate
Business modeling
AnyLogic
Project management
People management
Development management
Building a team
Development of tech specifications
Organization of business processes
Моя цель в данном случае была именно обеспечить подключение к каждому хосту по его понятному для меня имени, с возможностью поиска.
Для массового выполнения скриптов мы используем Ansible. Для авторизации на серверах — ключи.
По этой причине я предпочитал сначала посмотреть чем занимаются те, на кого я буду работать, и ответ на этот вопрос был одним из важных критериев выбора.
А почему не «проект» и «подпроект»?
У проекта есть более-менее четкое и принятое определение, что-то вроде (к сожалению пишу на память) «набор взаимосвязанных работ, направленных на получение какого-либо результата, имеющего обычно уникальный характер».
Мне кажется вы просто подпроекты выделили в отдельный термин. И каждый подрядчик, особенно если он не является частью вашей организации (а если является — это будет просто более завуалировано), будет достигать свои собственные цели, а вам придется следить, чтобы при этом он не забывал достигать и ваши, т.е. цели основного проекта. Штукатур на стройке тоже выполняет свой собственный подряд, хотя бригадир штукатуров может называть это проектом :) И его цель — заработать, — должна быть синергетически слита с целью главного инженера — построить.
Понимать вашу основную цель, разбираться со стейкхолдерами вашего проекта (вышестоящего относительно к «подпроекту» подрядчика) — это уже не забота подрядчика. У него свой небольшой мир, свой проект, где он будет делать то же самое, но в своих масштабах (и это хорошо — в идеале вам не потребуется погружаться на его уровень и сможете заняться своими делами).
И это касается не только ИТ: кого бы вы не нанимали поучаствовать в вашем проекте будет в вашей терминологии подрядчиком. Но это не отменяет необходимости формулировать стратегические/проектные цели, бюджет, ресурсы; доносить их до всех участников проекта, включая подрядчиков, и контролировать их соблюдение и достижение.
Мне Ваш подход понравился, хотя смысла от введения нового термина не вижу, но я полностью поддерживаю сам факт наличия у участников своих целей и необходимость с ними работать.
P.S. Прошу прощения, букв много получилось :)
Поддерживаю всецело, т.к. сам когда-то изучать управление проектами (и соответственно ушел от мысли, что все узнаю только на собственном опыте) начал именно с ДеМарко. У него много и других интересных книг, уже более «академических» на мой взгляд. Но конечно не надо им только ограничиваться (хотя я сначала именно так и пытался сделать:) ).
Используем. Суть та же, только названия другие — диагностика, постановка, разработка… А статусы мы используем только чтобы отразить реальное состояние задачи — в работе, в ожидании и т.д. Чтобы показать, что разработка выполняется на базе постановки, а постановка — по итогам какой-то диагностики, — мы используем связи «предыдущая-следующая», «связана с» и «блокирует» между соответствующими задачами.
С бэклогом полностью согласен, но не вижу необходимости скрывать от сотрудника его будущие задачи. Хотя планированием занимаются только руководители. Я как понимаю, у вас не много проектов открыто одновременно и бэклог один?
1. К задаче надо добавлять много доп полей (кто-то откажется создавать к ней подзадачи и ему надо будет указывать трудозатраты);
2. Каждому следующему разработчику вероятно придется искать историю задачи — если он получил только подзадачу. Или не придется, если ему передали основную задачу.
и т.д. В чем плюсы тогда? Просто в возможности работать так, как удобно на каждый конкретный тикет?
Мы работаем по второй схеме, но не с подзадачами, а со связями между задачами и объединением задач в проекты/версии.
И наконец самый больной вопрос, как вы планируете задачи? Все задачи, которые планируется взять в работу (не зависимо от того, когда работы реально начнутся) вводятся в систему сразу или менеджер/ответственный за проект вводит задачи по мере начала работ с ними? Как исполнитель узнает, что через некоторое время ему придется активно поработать?
Но для внутренней техподдержки это конечно не работает — никто со смежными подразделениями никаких «контрактов» не заключал и каждый из них требует столько, сколько придумает себе сам. В этом случае только правильная мотивация сотрудников ТП может выправить ситуацию, чтобы смогли «уговорить, объяснить и сделать вместе» (но не «сделать за»).
А первые я бы тоже предпочел (и предпочитаю) проводить с утра: мозг работает активнее и я «открыт» новым обсуждениям; утром еще нет загрузки дневной текучкой; и если назначить встречу на вторую половину дня, то необходимость подготовки к ней, мысленное планирование «съест» часть времени до этой встречи, а с утра этого времени будет меньше (и приходится явно потратить 15 минут на подготовку вместо фонового продумывания весь день).
И странно не обращать внимания на идею без реализации… Даже если пользоваться формулой ЦЕНА = ИДЕЯ * РЕАЛИЗАЦИЯ, то ИДЕЯ намного больше влияет на цену, чем РЕАЛИЗАЦИЯ — ведь она увеличивает реализацию в разы. Если поймать в нужный момент хорошую идею, то даже цена готового продукта даже при средней реализации возрастает в 10-20 раз!