| Сегодня 27 февраля, четверг |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера PM-Jedi/Записи в блоге |
 |
|
Девятая встреча Барнаульского PM-Community
2012-04-29 21:41:00 (читать в оригинале)В воскресенье прошла очередная встреча Барнаульского сообщества руководителей проектов.
К сожалению, в программе пришлось сделать небольшие изменения и доклад про методологию XP пришлось перенести на одну из следующих встреч. Поэтому, на докладе про делегирование решили время не экономить, а провести его в виде интерактивной flipchart-сессии.
Мы впервые попробовали доклады в таком формате. Кроме того, это был первый парный доклад на наших встречах. Естественно, эксперимент мы решили поставить на себе, поэтому выступали вдвоём с Натальей Оглоблиной – одной из основателей сообщества.
Конечно же, флипчарта ни у кого под рукой не оказалось (и с собой его, как ни странно, никто не принёс), поэтому рисовали на доске, поставленной на стул, а потом быстро всё стирали, "эмулируя" перелистывание страниц.
Поскольку доклад касался делегирования - одной из базовых задач менеджера, в работу понемногу включилась вся аудитория - около 20 человек, среди которых были и PMы, и руководители отделов, и владельцы бизнеса.
Мы определили делегирование как передачу части своих задач подчинённому с наделением его соответствующей ответственностью и полномочиями, разобрали основные выгоды от делегирования и попытались перечислить причины, которые мешают нам делегировать. Среди них мы выделили такие очевидные вещи как нехватку времени, недоверие сотрудникам, а также "гиперответственность" – стремление выполнить все порученные задачи и "комплекс супермена" – желание сделать всё самому и, тем самым, спасти мир. Кстати, пообщавшись с аудиторией, мы пришли к выводу, что делегировать можно, в общем-то, все задачи. Вопрос только в доверии, возможностях и компетенциях человека, которому мы их делегируем.
Вторая часть нашего интерактивного выступления была посвящена разбору известной многим матрицы Эйзенхауэра. Мы распределили задачи по срочности и важности, поговорили о каждом секторе отдельно и, в заключение, привели пример о том, что будет с компанией, если менеджер, занимающийся задачами из каждого квадрата, на полгода уедет в Антарктиду изучать пингвинов.
В общем, получилось в меру весело, в меру холиварно и очень интерактивно, что не может не радовать. Думаю, формат парных флипчарт-сессий можно продолжить и в будущем.
Кстати, мы с удовольствием поможем вам "прокачать" ваши навыки делегирования. В ближайшее время в Барнауле планируется несколько тренингов по этой тематике. Интересно? Пишите!
Девятая встреча Барнаульского PM-Community
2012-04-29 21:41:00 (читать в оригинале)В воскресенье прошла очередная встреча Барнаульского сообщества руководителей проектов.
К сожалению, в программе пришлось сделать небольшие изменения и доклад про методологию XP пришлось перенести на одну из следующих встреч. Поэтому, на докладе про делегирование решили время не экономить, а провести его в виде интерактивной flipchart-сессии.
Мы впервые попробовали доклады в таком формате. Кроме того, это был первый парный доклад на наших встречах. Естественно, эксперимент мы решили поставить на себе, поэтому выступали вдвоём с Натальей Оглоблиной – одним из основателей сообщества.
Конечно же, флипчарта ни у кого под рукой не оказалось (и с собой его, как ни странно, никто не принёс), поэтому рисовали на доске, поставленной на стул, а потом быстро всё стирали, "эмулируя" перелистывание страниц.
Поскольку доклад касался делегирования - одной из базовых задач менеджера, в работу понемногу включилась вся аудитория - около 20 человек, среди которых были и PMы, и руководители отделов, и владельцы бизнеса.
Мы определили делегирование как передачу части своих задач подчинённому с наделением его соответствующей ответственностью и полномочиями, разобрали основные выгоды от делегирования и попытались перечислить причины, которые мешают нам делегировать. Среди них мы выделили такие очевидные вещи как нехватку времени, недоверие сотрудникам, а также "гиперответственность" – стремление выполнить все порученные задачи и "комплекс супермена" – желание сделать всё самому и, тем самым, спасти мир. Кстати, пообщавшись с аудиторией, мы пришли к выводу, что делегировать можно, в общем-то, все задачи. Вопрос только в доверии, возможностях и компетенциях человека, которому мы их делегируем.
Вторая часть нашего интерактивного выступления была посвящена разбору известной многим матрицы Эйзенхауэра. Мы распределили задачи по срочности и важности, поговорили о каждом секторе отдельно и, в заключение, привели пример о том, что будет с компанией, если менеджер, занимающийся задачами из каждого квадрата, на полгода уедет в Антарктиду изучать пингвинов.
В общем, получилось в меру весело, в меру холиварно и очень интерактивно, что не может не радовать. Думаю, формат парных флипчарт-сессий можно продолжить и в будущем.
Кстати, мы с удовольствием поможем вам "прокачать" ваши навыки делегирования. В ближайшее время в Барнауле планируется несколько тренингов по этой тематике. Интересно? Пишите!
(Ссылка) Менеджер и его время, или Кому достанется обезьяна?
2012-04-27 16:18:00 (читать в оригинале)Подчиненные всегда стремятся переложить свою ношу на плечи начальника. Но есть способ, позволяющий руководителю расставить все по своим местам. Впервые статья “Management Time: Who's Got the Monkey?” вышла в ноябрьском выпуске HBR за 1974 год и с тех пор неоднократно перепечатывалась, став главным бестселлером журнала.
Почему руководителю обычно не хватает рабочего дня, тогда как подчиненным часто нечем его заполнить? Чтобы ответить на этот вопрос, внимательно посмотрим на структуру рабочего времени менеджера. Мы сразу увидим, что в ходе работы он вступает во взаимодействие трех разных типов: с начальством, другими менеджерами и подчиненными. Это позволяет нам разделить временной ресурс руководителя на три компонента:
- время менеджера, которым распоряжается его босс, – часть временного ресурса, которая расходуется на деятельность, навязываемую начальством. Если менеджер пренебрегает этими обязанностями, его ждет наказание;
- время, которое забирает система, – часть временного ресурса, затрачиваемая на выполнение просьб менеджеров других подразделений. Пренебрежение этой деятельностью тоже влечет за собой расплату, хотя не столь скорую и, возможно, опосредованную;
- время, которое менеджер тратит на собственные инициативы, – часть временного ресурса, которую менеджер тратит на реализацию собственных замыслов и выполнение обязанностей, взятых им на себя добровольно. Однако некоторую долю из этого запаса съедают подчиненные – назовем это временем, которым распоряжаются подчиненные. То, что остается, – время, распределяемое по собственному усмотрению. Разумеется, невыполнение собственных замыслов не сопровождается дисциплинарными взысканиями: ни начальство, ни система не могут наказать менеджера за пренебрежение обязанностями, о которых знает лишь он сам.
http://www.hbr-russia.ru/issue/1/1196/
(Ссылка) Менеджер и его время, или Кому достанется обезьяна?
2012-04-27 16:18:00 (читать в оригинале)Подчиненные всегда стремятся переложить свою ношу на плечи начальника. Но есть способ, позволяющий руководителю расставить все по своим местам. Впервые статья “Management Time: Who's Got the Monkey?” вышла в ноябрьском выпуске HBR за 1974 год и с тех пор неоднократно перепечатывалась, став главным бестселлером журнала.
Почему руководителю обычно не хватает рабочего дня, тогда как подчиненным часто нечем его заполнить? Чтобы ответить на этот вопрос, внимательно посмотрим на структуру рабочего времени менеджера. Мы сразу увидим, что в ходе работы он вступает во взаимодействие трех разных типов: с начальством, другими менеджерами и подчиненными. Это позволяет нам разделить временной ресурс руководителя на три компонента:
- время менеджера, которым распоряжается его босс, – часть временного ресурса, которая расходуется на деятельность, навязываемую начальством. Если менеджер пренебрегает этими обязанностями, его ждет наказание;
- время, которое забирает система, – часть временного ресурса, затрачиваемая на выполнение просьб менеджеров других подразделений. Пренебрежение этой деятельностью тоже влечет за собой расплату, хотя не столь скорую и, возможно, опосредованную;
- время, которое менеджер тратит на собственные инициативы, – часть временного ресурса, которую менеджер тратит на реализацию собственных замыслов и выполнение обязанностей, взятых им на себя добровольно. Однако некоторую долю из этого запаса съедают подчиненные – назовем это временем, которым распоряжаются подчиненные. То, что остается, – время, распределяемое по собственному усмотрению. Разумеется, невыполнение собственных замыслов не сопровождается дисциплинарными взысканиями: ни начальство, ни система не могут наказать менеджера за пренебрежение обязанностями, о которых знает лишь он сам.
http://www.hbr-russia.ru/issue/1/1196/
Как программисты пишут часы. Опасности общих моделей
2012-04-21 17:15:00 (читать в оригинале) |
| Именно так выглядят часы, дизайн которых придумал программист |
Не могу не поделиться замечательным случаем, который произошёл у нас в команде несколько дней назад.
В рамках нашего нового продукта ребята разрабатывали интерактивные виджеты для HTML5. И, в какой-то момент, дело дошло до анимации. Естественно, анимация представляла собой красивый и плавный переход между состояниями. Действительно, программисты довольно быстро и аккуратно всё реализовали, и я, вспомнив вебдевную молодость, выпросил недоделанный компонент "поиграться".
Но тут возникла непредвиденная заминка. Часы отлично шли до тех пор, пока секундная стрелка не доходила до отметки 59. А потом... Да, вы правы. Она красиво и плавно обращалась вспять и, пройдя весь циферблат в обратном порядке, возвращалась к отметке 0.
И ведь с точки зрения программистов всё выглядело логично! Действительно, чтобы анимировать переход от значения 59 к значению 0, надо, чтобы стрелка прошла в обратном порядке все числа от 59 до 0. Вот только в реальности никто никогда не видел часы, в которых стрелка возвращалась бы назад...
Итак, что же полезного мы можем вынести из этой ситуации?
- Во-первых: чтобы описать любой объект или явление, программистам приходится строить модель. По определению модели, часть факторов из реальной жизни остаётся "за бортом". И в этот момент особенно важно следить, чтобы модель, которую построили программисты, соответствовала модели, которую строит для себя пользователь. Действительно, когда я отключил анимацию, часы стали вести себя вполне ожидаемо (хотя и не так красиво).
- Во-вторых: тестирование должно обязательно проводиться на реальных данных в условиях, максимально приближенных к тем, который возникают у пользователя. Сейчас это кажется очевидным. Однако иногда, желая досконально протестировать работу продукта в граничных случаях и под нагрузкой, мы можем упустить проверку самых очевидных кейсов, которые, в силу их тривиальности, все просто игнорируют (и забывают).
- В-третьих: обычно программисты пишут программы, а не продукты. Они увлекаются описанием объектной модели, построением архитектуры и алгоритмов, забывая о том, что продукт должен собой представлять в реальности. То есть надо возвращать их с неба на землю. Здесь сильно помогает итеративный подход и частая демонстрация промежуточных результатов владельцу продукта (честно говоря, затрудняюсь более точно перевести скрамовское сочетание product owner).
- В-четвёртых: если вы пишите ТЗ на разработку внешней команде, по возможности описывайте исходный объект или процесс из реальной жизни, который лежит в основе создаваемого ПО. Это не только позволит программистам увидеть задачу шире, чем программный код, но и вы сможете более чётко сформулировать ключевые требования.С другой стороны я с огромным трудом представляю себе ТЗ, которое содержит фрагмент типа "при переходе от 59 к 0 стрелки должны двигаться по часовой стрелке". Такая детализация возможна разве что в системе жизнеобеспечения космического корабля, но мне такие задания, к сожалению, пока читать не доводилось. Поэтому описание реального объекта поможет команде более точно понять задачу.
- В-пятых: идеальный программист всегда немного аналитик. Он мыслит не только интерфейсами, классами и методами, но и объектами предметной области, понимает не только алгоритмы, но и бизнес-логику системы. И это одна из основных черт, которая отличает опытного разработчика от начинающего кодера (каким бы классным он ни был).
В заключение хочу сказать, что никоим образом не пытаюсь посмеяться над "глупыми программистами" или как-то ещё задеть их в профессиональном плане. У меня отличные ребята и классная команда. Просто есть вещи, которые кажутся настолько очевидными, что перестаёшь обращать на них внимание и видеть исключения из общих правил. И поэтому очень важно смотреть на систему с разных сторон: как менеджер по продукту, как аналитик, как программист, как пользователь системы. Попробуйте, и ваши продукты будут великолепны! Как у нас :).
