Не знаком с FreeIpa, судя по официальному сайту — это либо не совсем то, что надо, либо просто слишком сложно. FreeIpa реализует SSO, в т.ч. позиционируя себя как аналог MS AD, и позволяет выполнять массово одинаковые таски сразу на многих подчиненных машинах — если я правильно все понял. Возможно, вместе с этим она позволит и упростить подключение к каждому отдельному серверу, но это будет явно из пушки по воробьям в моем случае.
Моя цель в данном случае была именно обеспечить подключение к каждому хосту по его понятному для меня имени, с возможностью поиска.
Для массового выполнения скриптов мы используем Ansible. Для авторизации на серверах — ключи.
Все в руках того, кто заключает и подписывает контракт, а потом следит за его исполнением. И пока эти руки заинтересованы и ненаказуемы — Вы правы: «такие истории продолжатся в каждом втором госпроекте».
Применение, а не продажа. Если мы, как граждане страны, скинулись и заказали что-то разработать, то теперь это принадлежит нам (гражданам). И выгода от использования этого должна также идти нам (гражданам). Продавайте и возвращайте бабло в бюджет, например за вычетом процента за услуги коммерции. А отдельно продавайте свою поддержку к этому ПО и берите эти деньги себе.
Т.е. выбор «всю жизнь продавать сладкую воду» или «изменить мир» перед вами никогда не стоял? Скучно же на мой взгляд работать на компанию, которая делает примерно ничего, путь даже они вам платят достойно и работа полностью соответствует вашей квалификации. Зачем писать ПО, которое потом просто удаляется, даже если за это заплатят?
По этой причине я предпочитал сначала посмотреть чем занимаются те, на кого я буду работать, и ответ на этот вопрос был одним из важных критериев выбора.
я всё-таки настаиваю на предложенной терминологии: «проект» и «подряд», а не «проект» и «проект».
А почему не «проект» и «подпроект»?
У проекта есть более-менее четкое и принятое определение, что-то вроде (к сожалению пишу на память) «набор взаимосвязанных работ, направленных на получение какого-либо результата, имеющего обычно уникальный характер».
Мне кажется вы просто подпроекты выделили в отдельный термин. И каждый подрядчик, особенно если он не является частью вашей организации (а если является — это будет просто более завуалировано), будет достигать свои собственные цели, а вам придется следить, чтобы при этом он не забывал достигать и ваши, т.е. цели основного проекта. Штукатур на стройке тоже выполняет свой собственный подряд, хотя бригадир штукатуров может называть это проектом :) И его цель — заработать, — должна быть синергетически слита с целью главного инженера — построить.
Понимать вашу основную цель, разбираться со стейкхолдерами вашего проекта (вышестоящего относительно к «подпроекту» подрядчика) — это уже не забота подрядчика. У него свой небольшой мир, свой проект, где он будет делать то же самое, но в своих масштабах (и это хорошо — в идеале вам не потребуется погружаться на его уровень и сможете заняться своими делами).
И это касается не только ИТ: кого бы вы не нанимали поучаствовать в вашем проекте будет в вашей терминологии подрядчиком. Но это не отменяет необходимости формулировать стратегические/проектные цели, бюджет, ресурсы; доносить их до всех участников проекта, включая подрядчиков, и контролировать их соблюдение и достижение.
Мне Ваш подход понравился, хотя смысла от введения нового термина не вижу, но я полностью поддерживаю сам факт наличия у участников своих целей и необходимость с ними работать.
Про ресурсы и риски никогда не вредно освежить знания, а ДеМарко для начинающих романтиков.
Поддерживаю всецело, т.к. сам когда-то изучать управление проектами (и соответственно ушел от мысли, что все узнаю только на собственном опыте) начал именно с ДеМарко. У него много и других интересных книг, уже более «академических» на мой взгляд. Но конечно не надо им только ограничиваться (хотя я сначала именно так и пытался сделать:) ).
Для любого браузера найдутся сайты, которые его не поддерживают. Если используете винду, то родной ИЕ никуда не делся и для исключений можно использовать его. А для постоянной работы — то, что более удобно и надежно.
Мы работаем по второй схеме, но не с подзадачами, а со связями между задачами и объединением задач в проекты/версии.
Вы имеете в виду, что не используете типы деятельности как трекеры? Или все же используете?
Используем. Суть та же, только названия другие — диагностика, постановка, разработка… А статусы мы используем только чтобы отразить реальное состояние задачи — в работе, в ожидании и т.д. Чтобы показать, что разработка выполняется на базе постановки, а постановка — по итогам какой-то диагностики, — мы используем связи «предыдущая-следующая», «связана с» и «блокирует» между соответствующими задачами.
С бэклогом полностью согласен, но не вижу необходимости скрывать от сотрудника его будущие задачи. Хотя планированием занимаются только руководители. Я как понимаю, у вас не много проектов открыто одновременно и бэклог один?
Мне кажется, или итоговая схема комбинирует и минусы двух предыдущих:
1. К задаче надо добавлять много доп полей (кто-то откажется создавать к ней подзадачи и ему надо будет указывать трудозатраты);
2. Каждому следующему разработчику вероятно придется искать историю задачи — если он получил только подзадачу. Или не придется, если ему передали основную задачу.
и т.д. В чем плюсы тогда? Просто в возможности работать так, как удобно на каждый конкретный тикет?
Мы работаем по второй схеме, но не с подзадачами, а со связями между задачами и объединением задач в проекты/версии.
И наконец самый больной вопрос, как вы планируете задачи? Все задачи, которые планируется взять в работу (не зависимо от того, когда работы реально начнутся) вводятся в систему сразу или менеджер/ответственный за проект вводит задачи по мере начала работ с ними? Как исполнитель узнает, что через некоторое время ему придется активно поработать?
Ну на счет «не может»… Все таки уровень техподдержки прописывается в договоре (если это аутсорсинг конечно, а не собственная внутренняя поддержка) и инженер не может превышать этот уровень по собственной инициативе.
Но для внутренней техподдержки это конечно не работает — никто со смежными подразделениями никаких «контрактов» не заключал и каждый из них требует столько, сколько придумает себе сам. В этом случае только правильная мотивация сотрудников ТП может выправить ситуацию, чтобы смогли «уговорить, объяснить и сделать вместе» (но не «сделать за»).
По сути, как и любой другой «свод», SEBoK структурирует информацию, накопленную сообществом по системной инженерии. К сожалению, с указанным источником не знаком, судить не буду… Но благо SEBoK скорее в подаче и компановке материала, чем в его уникальности. Хотя и это уже хорошо — лаконичный свод по этой теме найти не так просто. Много книг, хороших, и по анализу эффективности, и по оценке рисков (это вообще отдельное направление), но где-то надо все свести воедино.
Наверно, стоит поделить встречи на требующие мозговой активности и «оперативки у начальства» (т.е. какие-то совещания, проводящиеся скорее «для галочки» или для отчета, в общем не требующие от вас креатива и мысленного напряжения). Вторые, по возможности, лучше вообще отменить. Ну или как описано тут, перенести на вторую половину дня.
А первые я бы тоже предпочел (и предпочитаю) проводить с утра: мозг работает активнее и я «открыт» новым обсуждениям; утром еще нет загрузки дневной текучкой; и если назначить встречу на вторую половину дня, то необходимость подготовки к ней, мысленное планирование «съест» часть времени до этой встречи, а с утра этого времени будет меньше (и приходится явно потратить 15 минут на подготовку вместо фонового продумывания весь день).
Мне кажется, цену идеи определяет покупатель. Кто вам заплатит за идею добычи огня из подручных материалов? Только тот, кому этот огонь нужен. И цену определит он :)
И странно не обращать внимания на идею без реализации… Даже если пользоваться формулой ЦЕНА = ИДЕЯ * РЕАЛИЗАЦИЯ, то ИДЕЯ намного больше влияет на цену, чем РЕАЛИЗАЦИЯ — ведь она увеличивает реализацию в разы. Если поймать в нужный момент хорошую идею, то даже цена готового продукта даже при средней реализации возрастает в 10-20 раз!
Моя цель в данном случае была именно обеспечить подключение к каждому хосту по его понятному для меня имени, с возможностью поиска.
Для массового выполнения скриптов мы используем Ansible. Для авторизации на серверах — ключи.
По этой причине я предпочитал сначала посмотреть чем занимаются те, на кого я буду работать, и ответ на этот вопрос был одним из важных критериев выбора.
А почему не «проект» и «подпроект»?
У проекта есть более-менее четкое и принятое определение, что-то вроде (к сожалению пишу на память) «набор взаимосвязанных работ, направленных на получение какого-либо результата, имеющего обычно уникальный характер».
Мне кажется вы просто подпроекты выделили в отдельный термин. И каждый подрядчик, особенно если он не является частью вашей организации (а если является — это будет просто более завуалировано), будет достигать свои собственные цели, а вам придется следить, чтобы при этом он не забывал достигать и ваши, т.е. цели основного проекта. Штукатур на стройке тоже выполняет свой собственный подряд, хотя бригадир штукатуров может называть это проектом :) И его цель — заработать, — должна быть синергетически слита с целью главного инженера — построить.
Понимать вашу основную цель, разбираться со стейкхолдерами вашего проекта (вышестоящего относительно к «подпроекту» подрядчика) — это уже не забота подрядчика. У него свой небольшой мир, свой проект, где он будет делать то же самое, но в своих масштабах (и это хорошо — в идеале вам не потребуется погружаться на его уровень и сможете заняться своими делами).
И это касается не только ИТ: кого бы вы не нанимали поучаствовать в вашем проекте будет в вашей терминологии подрядчиком. Но это не отменяет необходимости формулировать стратегические/проектные цели, бюджет, ресурсы; доносить их до всех участников проекта, включая подрядчиков, и контролировать их соблюдение и достижение.
Мне Ваш подход понравился, хотя смысла от введения нового термина не вижу, но я полностью поддерживаю сам факт наличия у участников своих целей и необходимость с ними работать.
P.S. Прошу прощения, букв много получилось :)
Поддерживаю всецело, т.к. сам когда-то изучать управление проектами (и соответственно ушел от мысли, что все узнаю только на собственном опыте) начал именно с ДеМарко. У него много и других интересных книг, уже более «академических» на мой взгляд. Но конечно не надо им только ограничиваться (хотя я сначала именно так и пытался сделать:) ).
Используем. Суть та же, только названия другие — диагностика, постановка, разработка… А статусы мы используем только чтобы отразить реальное состояние задачи — в работе, в ожидании и т.д. Чтобы показать, что разработка выполняется на базе постановки, а постановка — по итогам какой-то диагностики, — мы используем связи «предыдущая-следующая», «связана с» и «блокирует» между соответствующими задачами.
С бэклогом полностью согласен, но не вижу необходимости скрывать от сотрудника его будущие задачи. Хотя планированием занимаются только руководители. Я как понимаю, у вас не много проектов открыто одновременно и бэклог один?
1. К задаче надо добавлять много доп полей (кто-то откажется создавать к ней подзадачи и ему надо будет указывать трудозатраты);
2. Каждому следующему разработчику вероятно придется искать историю задачи — если он получил только подзадачу. Или не придется, если ему передали основную задачу.
и т.д. В чем плюсы тогда? Просто в возможности работать так, как удобно на каждый конкретный тикет?
Мы работаем по второй схеме, но не с подзадачами, а со связями между задачами и объединением задач в проекты/версии.
И наконец самый больной вопрос, как вы планируете задачи? Все задачи, которые планируется взять в работу (не зависимо от того, когда работы реально начнутся) вводятся в систему сразу или менеджер/ответственный за проект вводит задачи по мере начала работ с ними? Как исполнитель узнает, что через некоторое время ему придется активно поработать?
Но для внутренней техподдержки это конечно не работает — никто со смежными подразделениями никаких «контрактов» не заключал и каждый из них требует столько, сколько придумает себе сам. В этом случае только правильная мотивация сотрудников ТП может выправить ситуацию, чтобы смогли «уговорить, объяснить и сделать вместе» (но не «сделать за»).
А первые я бы тоже предпочел (и предпочитаю) проводить с утра: мозг работает активнее и я «открыт» новым обсуждениям; утром еще нет загрузки дневной текучкой; и если назначить встречу на вторую половину дня, то необходимость подготовки к ней, мысленное планирование «съест» часть времени до этой встречи, а с утра этого времени будет меньше (и приходится явно потратить 15 минут на подготовку вместо фонового продумывания весь день).
И странно не обращать внимания на идею без реализации… Даже если пользоваться формулой ЦЕНА = ИДЕЯ * РЕАЛИЗАЦИЯ, то ИДЕЯ намного больше влияет на цену, чем РЕАЛИЗАЦИЯ — ведь она увеличивает реализацию в разы. Если поймать в нужный момент хорошую идею, то даже цена готового продукта даже при средней реализации возрастает в 10-20 раз!