Где живут менеджеры

Сижу вот тут, читаю блог Александра Орлова - никого не трогаю. И вдруг от него прилетает очередной бессмертный пост :) Пост о том, что надо быть хорошим и умным, правильным человеком с большой буквы Ч. Не париться о мелочах, но думать о главном...в общем, обычная здравая мысль, которая оформилась после прочтения очередной умной книги в аэропорту :)
Но вот одна фраза (не знаю, кому принадлежит авторство, самому Александру или, напротив, он сам цитировал) в свою очередь взорвала мне мозг:

"Менеджеры живут на информационных потоках..."

Офигенно емко, выпукло, красиво и на 1000000% верно... здесь мы и живем, и все есть иллюзия, пока ты не поймешь этого... с пониманием этой простой и ясной мысли становятся не нужны Стивен Кови и другие консультанты, да и сам Александр Орлов уже не так необходим :) Просто с пониманием и принятием этого тезиса меняется система ценностей, меняется мотивация и поведение во всем...

Встречи AgileRussia.SPB

Свершилось историческое событие - в наших северных болотах "возобновились" (а учитывая, что перерыв был столь долог, что о них мало кто помнит) встречи сообщества AgileRussia! Наконец-то, наконец-то в нашу гавань зашли корабли гибкости и встали на якорь рядом с bootиком Piter the First!
Итак, в четверг, 18го ноября, в 19.00 по Ленинградскому времени Алексей Корсун, Михаил Карпов и Татьяна Васильева (пардон, лично знаком только с Алексеем :( ) собрали довольно значительную компанию людей (около 15 человек), которым интересен Agile. На повестке дня стояло два вопроса:
- "Распределенный Agile"
- "Автоматизация сборки и тестирования!"
Встреча проходила в формате свободной дискуссии, которую стимулировал и поддерживал Арексей Корсун. Сразу накидали достаточно много вопросов как на одну так и на другую тему - причем весьма разнообразных и интересных. Все это оставило у меня массу положительных эмоций, ведь это просто суперски, когда ты обсуждаешь интересную тебе тему в компании интересных, конструктивно настроенных людей. Приятным сюрпризом было встретить знакомого, которого не видел много (по-настоящему много) лет и законнектиться с ним через мойкруг. Увы, дела призвали меня и я вынужден был свалить по-английски не дождавшись даже пиццы, так что часть информации пришлось затем доставать из организаторов :)
Так вот! Засекреченный источник из узкого круга посвященных сообщил, что следующая встреча состоится через месяц (ориентировочно 18-го декабря) и на ней мы будем говорить о работе с требованиями! И это не может не радовать меня, как человека, 50% времени занимающегося именно этим!

Надеюсь, что со следующей встречи у нас будет полноценный репортаж со всякими интересностями! Всем удачи!

Оценки в Fixed-Price контрактах

Привет!

В последнее время мне все чаще приходится выполнять SWAGи для множества проектов, находящихся на различных стадиях (чаще всего на pre-sale). И основная проблема в том, что каким бы ни был контракт: Time-Material или Fixed-Price заказчик обычно требует определить бюджет проекта. Это, в принципе, разумно, так как без предварительных данных о бюджете менеджер на стороне заказчика обычно просто не в состоянии продвинуть проект (даже если он сам распоряжается деньгами).

В дебрях рунета наткнулся на небольшую статью об оценках затрат в Fixed-Price проектах:

http://www.enter-agile.com/2010/10/fixed-price.html?spref=fb. Статья несет в себе одну единственную полезную вещь, о которой стоит помнить планируя ЛЮБОЙ проект независимо от типа контракта. Мысль простая и разумная:

Оценивайте не модули (реализацию) а функциональность (требования).

Это действительно важно и крайне полезно, так как позволяет "играть" с содержанием(scope) проекта а так же очевиднее позволяет показать заказчику "тяжесть" каждой фичи. Хотя, надо сказать, бывают и другие ситуации:

1. Бывает необходимость разделять виды деятельности (например, разработка и тестирование) так как они будут выполняться различными субподрядчиками или финансироваться из различных бюджетов.

2. Зачастую бывает проще напрячь фантазию и разработать план, состоящий из "модульных" блоков, в составе которых делать глубокую декомпозицию до задач типа "разработать класс A" весом не более 8-16 часов, потому что только так можно показать ожидаемую продолжительность проекта заказчику, который не готов работать по Agile. Главное - даже не пытаться использовать этот план в дальнейшем! :)

Всем удачи! Точных вам оценок!

Суперцитата от Александра Орлова

Александр Орлов, как всегда, радует грамотными цитатами великих умов :) На этот раз в очередной раз попал в яблочко с моими текущими проблемами со своей цитатой Генри Форда:

"Я лучше нанял бы человека с энтузиазмом, чем человека, который все знает."

Человеки с энтузиазмом - приходите к мне на собеседование. Вы мне сейчас так нужны!

Коммуникации с заказчиком. О сборе требований.

Урааа! Наконец-то после месяца молчания я смог найти время для короткого (увыыы) и, пожалуй не слишком искрометного (позоооор!) поста о процессе сбора требований. Это скорее заметка на полях - некоторое время назад я просматривал слайдкаст доклада Александра Новичкова и Галины Карабановой "Коммуникации с заказчиком и проектной командой при сборе требований". В целом доклад несколько занудный (что, впрочем, типично для нашей отрасли :)), но несколько ключевых моментнов я для себя зафиксировал. Итак...

1. Правила хорошего слушания

• Перестаньте говорить
• Помогите говорящему раскрепоститься
• Покажите, что вы готовы слушать
• Устраните раздражающие моменты
• Сопереживайте говорящему
• Будьте терпеливы
• Сдерживайте свой характер
• Не допускайте споров и критики
• Задавайте вопросы
• Улыбайтесь
• Проявляйте искренний интерес

2. Восприятие информации

• На слух - 15%
• На глаз - 25%
• Аудио + Видео + Кинестетика - до 65%

По большому счету пункт 1 - это весьма вольное изложение идей активного слушания, о котором столько спето песен :) Активное слушание я люблю, стараюсь его активно использовать, так что авторы доклада молодцы, что затронули этот аспект. А вот пункт 2 будет вам гарантированно полезен если придется доказывать необходимость on-site визита к заказчику для уточнения требований или, напротив, для on-site визита к удаленной команде где-нибудь в Белоруссии для популярного выноса в массы идей проекта.

К слову сказать, мой последний проект показал на практике, что on-site визит - это просто волшебная штука и фактически must have во всех ситуациях, где вы делаете что-то хоть немного нетривиальное. Ну и не надо говорить, что особенно здорово, когда заказчик располагается в Вегасе, на Гавайах или хотя бы в Риме :)

Удачных вам проектов и непротиворечивых требований!