Знакома ли вам такая картина описанная в названии статьи и задумывались ли вы над ответом на этот вопрос. Как ни странно один и тот же ответ может подходить для двух этих различных случаев. И там и там выигрывает тот кто правильно понимает и работает с требованиями. Но если копнуть глубже, то обнаруживается что смысл заложенный в ответ в обеих случаях очень сильно отличается.
Рубрика «ПМ»
Почему ПМ часто проигрывают аналитикам, а те в свою очередь часто пасуют перед тестерами?
2021-01-08 в 9:23, admin, рубрики: Анализ и проектирование систем, аналитика, ПМУправление рисками на ИТ-проектах: что поменялось за последние годы
2018-05-29 в 7:08, admin, рубрики: Блог компании ТЕХНОСЕРВ, Карьера в IT-индустрии, ПМ, риски, управление персоналом, управление проектами, Управление проектом, управление разработкойДилемма управления рисками очень простая: либо ты перестрахуешься и заложишь все угрозы в бюджет проекта, который вырастет до небес, либо же ты пропустишь часть рисков и тогда получишь шанс красиво облажаться.
В первом случае не будет прибыли у компании и твоей премии, а во втором случится что-то более страшное. Но второй случай — это русская рулетка, может и повезти. На практике управление рисками — это всегда тонкий баланс между «разумным» и «достаточным».
Поэтому давайте чуть подробнее поговорим про некоторые риски проектов возросшие в последние годы. Часть из них не нова. Некоторые в реалиях нынешнего ИТ-рынка приобрели новые формы, окраску и монструозные черты.
Читать полностью »
Управляем большим длинным проектом: почему важно разговаривать словами
2018-04-17 в 7:00, admin, рубрики: Блог компании ТЕХНОСЕРВ, встречи, Карьера в IT-индустрии, коммуникации, письма, ПМ, разработка, управление персоналом, управление проектами, Управление проектом, управление разработкой
У меня в подчинении был один руководитель проектов, который никогда не собирал совещания. Он был немного хикки и обладал исключительным перфекционизмом (насколько это возможно для ПМа), что выражалось в стремлении всё происходящее фиксировать в почте. Письма были очень детальные, на несколько страниц: содержали все нужные описания, в них фиксировались все обещания, сроки, хотелки, большое внимание уделялось договорённостям и упрёкам в безответственности исполнителей. В общем, идеальные письма, последовательно излагающие ход событий, — хоть книгу по ним пиши.
Но проект шёл медленно: надо же написать письма, потом дождаться ответа и снова написать. Поскольку он был длинным, было ярко заметно, как на третий месяц начали накапливаться задержки и технический долг. Мой коллега продолжал писать письма, фиксируя каждое обязательство и каждый косяк и регулярно перенося сроки. Ситуация накалялась.
Я регулярно просил его собирать руководителей команд, работающих над проектом (инженеров по железу, разработчиков и так далее). Исходя из моего опыта, проблема, скорее всего, была в том, что команды не менялись информацией между собой.
Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.
Задержки продолжили копиться.
Читать полностью »
Что нужно знать, чтобы стать системным архитектором
2017-12-19 в 7:43, admin, рубрики: Анализ и проектирование систем, аналитики, архитектор, архитектура, Блог компании ТЕХНОСЕРВ, Карьера в IT-индустрии, ПМ, проектировщик, управление проектами, управление разработкой
Роли в проекте выглядят так:
- Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
- Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
- Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
- Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.
Потом в обратном порядке проект принимается.
Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая.
Дальше — имхо про то, что нужно от первых трёх ролей.
Читать полностью »
Ошибочное первое открытие менеджера
2015-08-17 в 14:06, admin, рубрики: менеджмент, ПМ, Управление продуктом, управление проектамиВдохновлен статьей «Самое первое открытие менеджера».
Горькая правда
Если резюмировать написанное в ссылаемой выше статье, получается, что все сотрудники кроме менеджеров в проектной команде это немотивированные люди, которым плевать на успех проекта. Это не так и я хочу копнуть глубже и напомнить о том, что такое – «Коллективная безответственность».
Читать полностью »
Российские космонавты отказываются брать пистолеты на орбиту
2015-02-10 в 8:23, admin, рубрики: космонавтика, медведи, МКС, ПМ, СОНАЗ, тайга, ТП-82, метки: ПМ, СОНАЗ, ТП-82 
Не все знают, что советские космонавты ещё со времён Гагарина брали с собой в полёт оружие. Сначала это был ПМ, а затем мощный охотничий ТП-82 с тремя стволами.
На первый взгляд кажется странным, зачем нужен пистолет: если лететь на станцию, то там любой выстрел приведёт к катастрофическим последствиям. Однако, смысл в этом был. Пистолет входил в спасательный комплект и хранился в посадочной капсуле. В случае аварийной посадки в тайге, что уже случалось, он мог спасти космонавтам жизнь, защитив от диких зверей.
Читать полностью »