Сходил на SECR 2009, в отличии от прошлого года, когда я выступал, в этом году у меня был стендовый доклад.

В субботу был на встрече клуба менеджмента - http://www.club-management.org/

Все началось с того, что  Алексей Яцына audumlo разместил буквально за день до мероприятия  пост о встрече.Так как раньше как то не удовалось попасть на встречи клуба, а тут выступал Алексей и его коллега Дмитрий Хлебников, да еще по теме очень близкой мне, то - сказано-сделано :)
Честно говоря, когда я ехал на встречу думал, что скорее всего это будет типа бесплатного семинара на пару часов, где вкратце рассказываеться про проект для пиара себя любимых, а нет – я жестоко ошибся. На деле мы сидели с десяти утра до пяти вечера, при этом коллеги не на минуту не позволили аудитории расслабиться и зевать. Алексей и Дмитрий сменяя друг друга на проятжении чуть ли не семи часов, сомоотверженно рассказывали про очень интересный консалтинговый проект :)  Проект заключался в  выстраивании системы управления в одной компании, внедрении там проектного управления (эти мне и было интересно) и завязанного на ней системы мотивации (всякие KPI и тд).

Скажу прямо, я еще не разу не встречал, что бы профессионалы (а они  Профессионалы с большой буквы),  вот так делились подробной информацией и вступали в дискуссии с коллегами.  За себя скажу, что между мной и Дмитрием завязалась жаркая дискуссия – нужен ли учет времени как инструмент управления в проектах (в том числе и разработки ПО) или это лишнее.

В общем хочу высказать им огромную благодарность, за отлично проведенное время :)

Клиенты в ресторане сидят, кушают. Вдруг замечают, что все официанты ходят с ложками в карманах, подзывают одного из официантов и спрашивают его

- Любезнейший, а почему все официанты в вашем заведении носят с собой ложки в карманах?

- Да видите ли, у нас работала консалтинговая фирма, после чего нас сертифицировали по ISO 9001.

Консультанты изучили все наши бизнес-процессы и выявили такой факт: клиенты ресторана часто роняют ложки на пол и поэтому нам, официантам часто приходится бегать на кухню и нести клиентам новые ложки.

На это мы тратим много времени. А теперь нам не приходится бегать на кухню. Мы может обслужить больше клиентов и более качественно.

- а, понятно. А почему у вас на брюках висит шнурок?

- Да, понимаете, опять же консультанты рекомендовали нам сократить время на туалет. То есть после каждого посещения туалета нам приходится мыть руки. Мы теряем

время. А так, дергаем за шнурок, автоматически вынимаем причиндалы и справляем наши естественные надобности. Руки чистые.

- Любезнейший, а как вы заправляете без рук ваши причиндалы обратно в брюки?

- Вы знаете, все по-разному, но я делаю это ложкой.

Давеча с друзьями ездили смотреть машину в автосалон, друг решил сменить старый драндулет на новый для расширившейся семьи и пригласил своих друзей оценить выбор.

И вот в процессе посещения произошла приинтереснейшая история.

Был давеча на круглом столе по обсуждению разных методологий разработки ПО. Говорили много и красиво о самих методологиях, о том, что некоторые методологии несут всякие  выгоды  компании и т.д. При этом  во время обсуждения поймал себя на мысли, что во время обсуждения методологий ни разу не поднимался вопрос о  критериях применимости конкретной методологии или практик к тому или иному проекту.

В данном посте, хотел бы собственно поговорить о применимости той или иной методологии к тому или иному проекту. Проще говоря, когда на проекте выстраивать процессы по RUP/CMMI, а когда использовать Agile практики?

В блоге cartmendum мы пообщались по поводу Agile команд,   я изложил свою точку зрения, о том что универсальных бойцов в команда Agile не может быть  Один человек на проекте не может быть одновременно и  хорошим спецом и в сборе-анализе требований и в кодировании и в тестировании в силу некоторых обстоятельств. Почему? Я решил изложить ниже:
 

Вот такой незайтеливый заголовок :) Шел сегодня на обед и задумался, а для чего собственно  компании разработчики ПО начинают автоматизировать процессы?  Имеется в виду не автоматизация одной какой то узкой области, например код-ревью или сбора требований, а комплексная, сквозная автоматизация процессов с помощью ALM-подобных систем. Пришел к выводу о трех целях.

1. Считать бабло
2.  Автоматизировать бардак
3.  Ради откатов
 

Парижане, удивительный люди, гуляя по Парижу, создается впечатление, что большая часть местных не работает, а коротает время сидя в кафе потягивая неспешно кофе или развалившись на травке где нибудь в Люксембурском саду почитывает книгу.

Решил написать краткий опус на вышеозвученную тему.

Почему в кризис вопрос упорядочивания и автоматизации  процессов разработки ПО стоит особо остро?

Скажем так, в кризисной ситуации собственники бизнеса особо ачинают остро чувствовать последствия бардака, и ищут способы повысить эффективность этого самого бизнеса, без привлечения дополнительного капитала. Однако как показала жизнь, практика сокращения издержек засечет сокращения персонала не особо эффективна.  В ЖЖ уже писались заметки про то, что например разгон отделов маркетинга приводит к обратным от ожидаемых результатам. А разгон сотрудников отучающих за организацию обучения вообще ведет в вполне недалекой перспективе к потере конкурентоспособности компании.

В первую очередь обратить внимание компаниям в условиях кризиса, надо на внутренние процессы, которые формируют добавленную стоимость продукта производимого компанией. Понятно, что «пока гром не грянет, мужик не перекреститься», однако лучше поздно, чем никогда.
 

«Кризис!», «кризис!» слышится со всех углов, куда не глянь, все обсуждают кризис. Вот у одного срезали зарплату, у второго не дали премию, а у третьего сократили треть персонала. Вот про третье мы и поговорим. Нет, не про юридические процедуры сокращения персонала, а про то чем грозит подобное бизнесу, и какие риски появляются вследствие сокращений.

Итак, как полагается в какой то компании сократили людей, но работа то идет, и через некоторое время появляется нужда в знаниях . Например случилась кризисная ситуация в проекте, кто то ляпнул, что она уже была и Петрович отлично из нее выкрутился, все ринулись к Петровичу, а его...тю-тю, сократили. И  источника знаний  нет, что ходячего, что бумажного, ибо как водится на постсовковом пространстве, знания это главное богатство работника, и знаниями он не спешит делится, ибо как только он поделится знаниями, то сразу же сработает принцип «незаменимых работников у нас нет».

Посему знания компания должна собирать потихоньку, извлекая их крупицами, и не создавая иллюзию дискомфортного состояния у хранителя знаний, что из него выжимают все соки.  Такие знания в компании оформляется как best practices.

Вот о них мы и поговорим, применительно к проектам :)