Вы стоите на пороге новой организации и перед вами комплексная задача по запуску нового оборудования, системы и/или программы. Продажную составляющую пропускаем и переходим непосредственно к исследованию задачи, где наш проект очерчен бюджетом, сроками и задачами. Важно не забывать, что одна грань успешного запуска — психология входа на проект и взаимодействия с сотрудниками. Ведь любой технологией управляет человек, и именно с ним произойдёт первичный контакт по сбору данных.
Читать полностью »
Рубрика «управление рисками» - 3
Правила, которые помогают мне выжить в новом коллективе и запустить систему. Начало
2016-11-03 в 14:19, admin, рубрики: аналитика, бизнес-модели, пять почему, управление проектами, управление разработкой, управление рискамиУправление проектами в L&D
2016-08-08 в 8:37, admin, рубрики: gtd, Блог компании TESTutor, менеджмент проектов, проектный менеджмент, работа над новыми технологиями, работа над продуктом, риски, совершенствование, улучшение навыков, управление проектами, управление рисками
Главная цель L&D — перемены. Это просто не стоит оспаривать, изменения неизбежны и L&D (обучение и развитие в компании) автоматически будет успешным. Успешный L&D нуждается в осторожном планировании и менеджменте – и тут вступают в игру правила управления проектами. Давайте поговорим о них.Читать полностью »
Un-FuckUp-able Development Protocol (UDP)
2016-08-04 в 14:40, admin, рубрики: разработка, разработка программного обеспечения, разработчикам, управление временем, управление задачами, управление людьми, управление проектами, управление проектами и командой, Управление проектом, управление разработкой, управление рисками, Читальный залНедавно после очередного Team Building’a получил от одного Коллеги-Графомана письмо-притчу про большую кнопку «сделать всё хорошо». Он и раньше баловался изобретением велосипедов, но, в этот раз конструкция показалась мне очень удачной. Кому интересно — прошу-приглашаю под кат. С его разрешения дословно:
В эту сиесту на веранде практически никто не курил, потому, что все ушли на очередной двухдневный SCRUM тренинг. Джонни устало окинул взглядом присутствующих: Дёму и Варю. Они тоже не были в восторге от происходящего, было слишком жарко и душно, лето в Долине было в самом разгаре, и казалось, что на улице даже жарче чем в Task Tracker’е.
Человеческий фактор остается самым сильным, но выгодным риском в разработке ПО
2016-07-19 в 16:57, admin, рубрики: agile, корпоративная культура, разработка по, управление проектами, управление разработкой, управление рисками, человеческий фактор
Изображение с сайта projectimo.ru
Даже в такой продуманной и формализованной сфере, как разработка программного обеспечения, не перестает быть актуальным вопрос управления рисками. Можно ли вообще управлять неопределенностью, случайными величинами?
Оптимисты утверждают, что их можно классифицировать и научиться предугадывать. В случае разработки ПО риск-менеджеры пытаются предугадать, какая часть проекта вызовет больше проблем, на каком этапе это случится, кто в команде – самое слабое звено, какие фичи могут дать задержку по времени. Сложнее понять, какие фичи заказчик захочет доработать в процессе разработки – как говорится, на полном ходу. Высший пилотаж – добавить в план разработки ту функциональность, о которой заказчик забыл сказать или вообще не знал, что она ему понадобится.
А риск того, что проект неожиданно покинут ключевые разработчики, вообще приводит в ужас многих риск-менеджеров. Читать полностью »
11 последствий широкого ассортимента
2015-10-20 в 8:47, admin, рубрики: интернет-маркетинг, логистика, маркетинг, ошибки, проблемы стартапа, психология, Управление продажами, управление проектами, управление рисками 
Сложность выбора, психологическая нагрузка, дорогие описания и другие последствия, которые ждут тех, кто вышел на путь широкого ассортимента.
Каждый должен понимать, с каким количеством проблем ему придётся столкнуться при создании широкого ассортимента и понимать, готов ли он к этому.
Читать полностью »
Occasional Project Manager. Можно ли стать менеджером проекта случайно?
2015-08-07 в 9:49, admin, рубрики: руководитель проекта, руководство проектами, управление командой, управление проектами, управление проектами и командой, Управление проектом, управление рискамиВ один прекрасный момент шеф подошел к вам, отметил ваши организаторские способности и предложил возглавить группу коллег (команду) для реализации нового проекта. Как это может изменить вашу жизнь?
Почему это произошло и зачем нужен проектный менеджер или руководитель проекта? У кого-то в компании появилась идея, реализовав которую, можно достичь улучшений в работе компании или получить прямой доход. Реализация этой идеи не укладывается в рамки обычной операционной деятельности (по разным причинам). Далее, на одном из совещаний, на котором присутствовал ваш шеф, идею поддержало руководство и ее реализацию поручили вашему шефу, поскольку он либо был ее инициатором, либо тематически реализация этой идеи ближе всего именно к его сфере ответственности. При этом реализация идеи требует отвлечения как минимум нескольких сотрудников от обязанностей, прописанных в их должностных инструкциях (в непроектных организациях участие в проектах зачастую не включается в должностные обязанности), то есть объем и сложность работ слишком велика, чтобы поручить ее выполнение одному или даже нескольким сотрудникам одного подразделения, либо требует опыта, знаний и навыков, которыми никто в компании не обладает, либо и того и другого одновременно. Поэтому, для реализации этой идеи необходимо запустить отдельный проект.
Почему бы вашему шефу самому не стать руководителем этого проекта? С его стороны ситуация может выглядеть так. Идея, которую ему необходимо реализовать, требует планирования, координации действий как минимум нескольких человек, контроля результатов их работы, отдельного бюджета и его контроля и, что самое важное — времени, которого, возможно, просто нет у самого шефа ввиду загруженности в рамках управления текущей операционной деятельностью. В этой ситуации он вполне логично пользуется одним из методов управления – делегированием ответственности за этот результат. Одним из основных принципов проектного управления является персональная ответственность за вполне конкретный результат. Поэтому в подобной ситуации вполне логичным решением будет назначение ответственным одного из своих подчиненных, который должен обладать несколькими важными качествами. Во-первых – теми самыми организаторскими способностями, во-вторых — пониманием, что нужно сделать для достижения заданного результата, в том числе умением составить план реализации проекта. Это, так сказать, минимум.
Делегирование ответственности за результат вам как руководителю проекта не снимает итоговой ответственности с вашего шефа перед вышестоящим руководителем, который поручил ему реализацию идеи, но уменьшит персонально им затраченное время на достижение конкретного результата. Не забывайте об этом, понимание этого факта поможет вам, когда в ходе реализации проекта возникнут проблемы и вам потребуется помощь (но об этом в другой статье).
Самым первым, с чем вы столкнетесь, будет необходимость тратить значительную часть своего рабочего времени на планирование работы всех членов команды проекта, особенно если эта команда состоит из работников различных подразделений и/или необходимо привлечение внешних подрядчиков. Вторым важным моментом будет то, что результат работы всей команды шеф будет спрашивать именно с вас, для этого он, в конце концов, вас и назначил руководителем проекта. Третьим важным моментом будет то, что, скорее всего, шеф с вас будет спрашивать именно результат, включая промежуточные результаты, а не контролировать процесс достижения результата, поскольку назначив вас руководителем проекта, контроль выполнения работ необходимых для получения результата он поручил вам. Сам он при этом фактически становится Куратором проекта.
И вот когда к новоиспеченному руководителю проекта приходит понимание всех этих моментов, у него иногда возникает некий «кризис ответственности». С одной стороны, результат проекта почти всегда сформулирован так, что новоиспеченный руководитель проекта вроде бы не должен за него отвечать, исходя из того, что описано в его должностных обязанностях. С другой стороны, бонусами за достижение результата проекта часто могут быть дополнительная финансовая премия и/или возможное повышение. Да и сама возможность примерить на себя «пиджак менеджера» тоже может быть интересной. Поэтому очень важно на старте проекта договориться с шефом о границах вашей «управленческой самостоятельности», даже если шеф сам не настоял на этом. Например, текущее отклонение по срокам исполнения на один — два – три дня не требует от вас немедленной эскалации (официального уведомления) этой ситуации шефу, конечно при условии, что вы сами знаете, как в дальнейшем устранить отставание. А выявление более длительного отставания, обязательно нужно эскалировать. Аналогичная история с возможными отклонениями по стоимости и объему работ, выполняемых подрядчиком по контракту. И хотя большинство подрядных работ в России выполняется по контрактам с фиксированной ценой и фиксированным объемом работ, далеко не все и не всегда идет так, как записано в контракте.
Проекты могут быть различной длительности, от нескольких недель или месяцев, до нескольких лет. Как длительность участия в проекте может повлиять персонально на вас, если вы впервые стали руководителем проекта? Как бы это странно не прозвучало, но далеко не все люди, работающие в компаниях, стремятся стать руководителями. Если проект небольшой по длительности (несколько недель или месяцев), то вы несомненно получите полезный опыт управления и организации работы других людей, который позволит по-новому взглянуть на ваше место в компании и подстегнуть ваши амбиции. Если проект довольно длительный (обычно, значительно больше года), то, кроме вышеописанного, вы неожиданно для себя можете столкнуться с интересным эффектом. Работая в качестве руководителя проекта, вы, развивая ваши навыки управления, с некоторой вероятностью «притупляете» навыки, которые оттачивали, будучи предметным специалистом. Поэтому если вы выбрали роль руководителя проекта, предварительно не решив для себя, собираетесь ли вы в дальнейшем переквалифицироваться в управленца, то учитывайте, что возвращение к прежней работе может быть сопряжено с дополнительными усилиями по восстановлению частично утраченной квалификации. Но разве осознание успешности реализации вашего первого проекта не стоит всех затраченных для этого усилий?
Успехов вам в управлении проектами и покорении корпоративного Олимпа!
Автор: Олег Тумасов, главный редактор журнала «Управление Проектами».
Читать полностью »
Порядок подготовки ТЗ на информационную систему. Ликбез для финансового руководителя
2015-06-29 в 12:53, admin, рубрики: техническое задание, управление проектами, Управление проектом, управление рисками, финансы в ITВведение
Современные финансы, собственно как и деятельность первых менял, это обработка информации. Только если менялы обходились в лучшем случае абаком, финансовому директору приходится иметь дело с неизмеримо большим потоком информации и инструментами для его обработки. Сложность современных
инструментов обработки финансовых данных приводит к тому что, даже если программное обеспечение используется «из коробки», без модификаций, процесс его внедрения в компании может быть достаточно длительным и болезненным. И чтобы этот процесс когда-нибудь закончился и был успешным, финансовый директор оказывается вовлеченным в него самым непосредственным образом. И начинается этот процесс с подготовки технического задания.
Примечание. Мы понимаем что есть еще стандарты на ТЗ от IEEE, ISO и пр. Однако с чего-то же нужно начинать ;-) Мы в Аксиан) придерживаемся свободных взглядов на ТЗ — главное использовать в нем общий с Заказчиком язык.Читать полностью »
Услуги в области ИТ: Матчасть. Часть 2. Формула услуги
2015-03-31 в 3:49, admin, рубрики: Блог компании ICL Services, Матчасть, Теория услуг, термины, Управление продуктом, управление проектами, управление рисками, Управление услугами, услуги, финансы в IT, формула услуги Есть хорошее определение услуги, данное в ITIL. Официальный перевод: услуга/сервис – это предоставление ценности заказчикам через содействие им в получении конечных результатов, которых Заказчики хотят достичь без владения специфическими затратами и рисками.
Это определение я буду называть «формулой» услуги.
На примере такси схематично формула выглядит так:

Почему Индийский аутсортинг обречен
2015-03-29 в 19:53, admin, рубрики: аутсорсинг, Карьера в IT-индустрии, Программирование, управление людьми, управление проектами, управление рисками, фриланс 
Опыт поиска работы на бирже Elance разгорелось горячее обсуждение темы способов конкуренции с индийцами и пакистанцами на площадках сайтов для фрилансеров. В продолжение этой темы публикую свой вольный перевод статьи Евгения Розинского о проблемах краудсортинга в Индии. По словам Евгения он имеет 15 летний опыт в этой области и знает о чём говорит. Это взгляд из США, со стороны работодателей. Статья была опубликована ещё в 2013 году, но проблемы которые в ней рассматриваются сегодня стали ещё более актуальными.
Индийский ИТ-аутсорсинг стал бизнесом, который поставлен на поток. Бизнесом без каких-либо инноваций Единственным сомнительным плюсом которого является дешевизна. Но не миф ли это?
Это не попытка написать научную статью или предсказать будущее. Это просто личное мнение, сложившиеся у меня на основе более чем 15 лет работы с различными поставшиками услуг в Индии и по всему миру. Не стоит рассматривать статью как попытку сформировать стереотип для каждого сотрудника страны с населением 1,2 миллиарда человек. На протяжении многих лет мне посчастливилось работать с блестящими индийскими инженерами и менеджерами, как в Индии, так и в США. Этой рецензией я пытаюсь описать индустрию аутсорсинга Индии в целом и отметить характерные проблемы с которыми мы сталкиваемся в качестве клиентов, а не людей, работающих там.
Мои выводы и предположения базируются на том, что многие компании переходят к более гибким стратегиям разработки, в которых процесс принятия решений и способность адаптироваться является ключевой.
Читать полностью »
Управление программными проектами: процессы, инструменты, методики
2015-03-23 в 8:42, admin, рубрики: управление временем, управление задачами, управление качеством, управление проектами, управление рискамиСуществуют разные представления о том, как ведётся творческая работа. Для многих людей творец – это личность (поэт, художник, изобретатель), которая создаёт своё творение в момент озарения. Управлять озарением? О, нет! Это невозможно!!!
Тем не менее, задача управления творчеством во все времена была актуальна. Инвесторам, менеджерам, государству хотелось бы иметь предсказуемость на счёт того, когда будет выпущен разрабатываемый творческий продукт (будь это книга, самолёт, компьютерная программа или кинофильм).
Творческая работа может вестись как индивидуально (одним творцом – учёным, художником, композитором или поэтом), так и коллективно (когда над созданием произведения работают коллективы людей разных специальностей). В данной статье мне бы хотелось сконцентрироваться на вопросах управления творческими коллективами на примере распределённого коллектива программистов, художников и дизайнеров из трёх стран, который выпускает приложение, продаваемое во всём мире. Каждый год продаётся более 10 миллионов экземпляров. Годовая выручка – 1 миллиард долларов.
Предположим, мы захотели открыть ресторан. По каким критериям Клиент будет оценивать его? Конечно, это кухня, дизайн и обслуживание. Обычно, наибольшее количество «глюков» происходит в процессе обслуживания, т.е. там, где велик человеческий фактор. Красивенькая молоденькая официантка вроде бы привлекает Клиентов. Но у неё испортилось настроение, и вместо доброжелательного отношения, она начинает хамить. В результате, вместо привлечения происходит отваживание Клиентов. В индустрии разработки ПО такое просто недопустимо. Необходимо, чтобы специалисты разных специальностей взаимодействовали друг с другом, а барьеры в коммуникациях и всякие субъективные вещи сводились бы к нулю. Поэтому при работе в большой интернациональной команде неформальные связи между людьми заменяются формализованными бизнес-процессами, а вместо субъективных оценок (хороший, прикольный, клёвый) используются метрики и показатели качества.
В больших проектах выгоднее купить нужного специалиста на рынке, даже если его зарплата кажется чрезмерной. При съёмках кинофильма, продюсер не учит своего сценариста писать диалоги, если тот не умеет этого делать, а просто покупает сценариста для написания диалогов на рынке. Аналогичным образом поступают при разработке приложений. Если возникает недопонимание между командами из разных стран, то одну команду отправляют в длительную командировку. При миллиардной выручке затраты на командировку не имеют значения: главное – выпустить продукт в срок.
Читать полностью »
