Показаны сообщения с ярлыком people management. Показать все сообщения
Показаны сообщения с ярлыком people management. Показать все сообщения

вторник, 10 апреля 2012 г.

Software people. День первый.

Побывал сегодня на softwarepeople, вобще конференция считается самая-самая айс на нашем пост-советском пространстве. 
Потому уже можно поставить себе ачивмент - "побывал на swp" =) 
Куча знакомых и не знакомых лиц, известные гуру и т.д., в общем хороший повод по социализироваться)

Коротко опишу доклады, на которых побывал и впечатления:

Мое мнение мне прям самому кажется излишне негативным. (так, что если что есть альтернативный источник субьективных оценок - отчет от Максима Цепкова)


Первым был доклад 
Джеффа Де Люка (Nebulon Pty Ltd) "Почему мы терпим неудачи. Разработка ПО в наши дни (Why We Fail. A Discussion of Software Development Today)"
Не хочется прям быть такой негативной сволочью, но чел был - Кэпом(тм).

Рассказал про то, чтоб все практики уже известны - код ревью, дизайн-ревью, автотесты и т.д. Надо иметь дисциплину и поддерживать их. 



Чуть-чуть рассказал про модель развития команды такмана - форминг-сторминг-норминг-перформинг. Рассказал об внесении изменениях и связанным с этим падением продуктивности, через что ажайл индустрия опять же уже прошла 100500 раз(например быстрое гугление "change chaos" дало данный линк).

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

После выступления решил, что хватит с меня иностранных докладчиков пошел послушать:
Сергей Высоковских (Нетвокс Лаб) Альтернативный метод визуализации хода IT-проектах

Сергей показывал способ визуализации хода проекта в виде эдакой военной карты наступления с штриховым\пунктирным кодированием прогресса задач, цветовым кодированием их типов, указания стрелочками порядков выполнения и т.д., эдакое проецирования прогресса на плоскость. Тема новая, но мне была не слишком интересной и потому я убежал слушать
Дмитрия Ханецкого (IBM) про "Эффективное управление жизненным циклом разработки ПО"
Дмитрий рассказывал про ibm jazz это эдакий комбаин, который позволяет тем или иным образом совместить в себе чуть ли не все продукты IBM от управления требованиями и моделирование бизнес процессов, до выполнения задач, проектирования, разработки, тестирования, отчетов, деплоймента и т.д.
С возможностью оттрасировать все и вся, что в принципе удобно.

Рассказывал про 100 миллионов строк в каком-нить софте для управленяи машиной, и 20ки миллионов для банков со всеми их регуляциями и правилами.
Для какого-нить банка или производителя автомобилей я думаю очень даже удобно и вполне себе решение, может даже применимо для компаний для разработки ПО, если вы готовы отвыкать от привычных жиры\редмайна. Для меня польза от доклада -  довольно сомнительна)

После послушал 
Василия Малинова (Oktogo.ru) про "Роль продукта в успехе привлечения инвестиций", увлекательно конечно узнать про размеры инвестий и на каких стадиях их дают, но не более того, видимо все существенное я пропустил пока искал, что-то более интересное (в главном зале в это время шла живая сессия БДД\ТДД, что в общем то то же не ново).

После Василия шел  Станислав Калканов (жж, там же есть ссылка на презентацию ) про "Управление инновациями в стиле Lean Startup", т.к. я был 1 из 3х-4х человек читавших книжку (думаю допишу по ней отзыв через неделю-другую, как будет свободное время).

Станислав сказал, что  - извините, буду рассказывать - основы, потому в общем-то провел основное время общаясь в калуарах, но судя по отзывам которые, я собрал тему он не сильно донес(т.к. книжку реально сложно уткнуть в 30 минут, да еще и с вводными), хотя тема реально интересная.

После был обед, к обеду претензий нет, он был вкусный)
Во время обеда с коллегами обсуждали ажайл\не ажайл, есть ли от него толк и польза и в  результате дискуссии (мы кажется были единственные кто громко ржал во время обеда) появилась мысль : "процесс, как средство позволяющее уменьшить мудаковатость соседней команды в 2 раза =)"

После обеда хотел послушать 
Дмитрия Евтеева (Positive Technologies) про "Собираем команду хакеров", да докладчик там чето долго колупался, а потом еще сказал ждем 5 минут, пока "что-то там".
Я решил, что лучше пойду пока кого другого послушаю, в главном зале шел Асхат Узарбаев с "Л
идерством в стиле Lean" (слайды) и хотя бы зажигательно рассказывал про свои любимые темы типа Лина, Ажайла, рассказывал про цикл Деминга PDCA, о том, что существенная часть команд останавливаетсья в развитии потому, что "итак вроде не плохо",  рассказывал про превращение работы в игру (сделай 20 тасков и получи ачивмент, стань программистом 80го уровня =)), в принципе идея не плохая тренд с бейджами и очками, вполне такой живой во всех социальных приложениях и игры, как средство получения фана от работы вполне себе идут.

После послушал 
Влада Балин(жж) (Финам) про "Разработку как процесс коллективного решения проблем".

Вот он рассказал классно, просто, понятно с примерами и вполне насущный вопрос: о том, что вся разработка ПО - по сути проектирование и как это проектирование делать правильно.

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

У нас же сборка\выкатка - дело минут, тестировать можно сразу и фактические единственное, что осталось - это ТОЛЬКО проектирование.

А проектирование - это решение конкретной проблемы пользователя, ну по сути пользователи ВСЕГДА прибегает с РЕШЕНИЕМ своей проблемы - "нужно переписать риск-сервер!"(реальная проблема: в риск-сервере 10 критичных багов, их фикс займет 3 дня), "нужно сделать все на .net"(реальная проблема: никто не хочет лезть в этот код на дельфи), чаще всего пользователь даже хорошо знает о своих проблемах, просто сразу предлагает свое решение, и зачастую не самое оптимальное.

После того как проблема определена, наступает обычный инженерный этап проектирования:
- найти ВСЕ возможные варианты
- оценить их затратность, побочные эффекты и т.д.
- откинуть невозможные
- выбрать получше
а не сразу "переписать риск-сервер" =)

Ну и дальше уже рассказывал, как эти процессом управлять, как руководителю этого процесса проверять, что люди занимаются делом, а не "я провожу мыслительный эксперимент" и хрен ты его проверишь) Доклад мне в общем понравился.



После послушал Андрея Сикорский (РИА Новости) про "Вниз по «скунсовой норе» или как внедрить UX в разработку".

Андрей рассказал про уровние юзабилити в вашей компании, (оригинал рассказал -
http://www.useit.com/alertbox/maturity.html), дал метрики индикаторы, как посчитать на каком вы уровне, + рассказал, что в принципе предшествует внедрению юзабилити в компании(падение продаж, отток пользователей, и т.д.).
Рассказал откуда его можно начинать внедрять(либо по партизански, либо имея чемпиона "бегемота" - большого босса, который скажет - "что за Х у вас тут твориться !?"), в общем интересно, НО "маловато будет")

После пошел слушать Сергея Минюрова про "Семантическая формализация требований: опыт построения проектной базы знаний", но докладчик был настолько скушен и не смог за первые 5 минут внятно донести - ни какие прям вот реально насущные проблемы со сбором требованиям у меня есть, и как их так прям резко можно решить его чудесным способом, что я просто ушел слушать Виктора Кузьмина (AlterGeo)  про то "Как выстроить разработку сервиса под несколько мобильных платформ".
Было довольно интересно. Рассказали зачем вам вобще мобильное приложение, что оно дает вместо допустим сайта(гео-* штуки, адресная книга), какие проблемы могут возникнуть.

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

Пользователи (вот ведь подлецы) существа ленивые и вот прям не очень то хотят обновлять свои приложения и потому их надо мотивировать:

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

Рассказали про свои проблемы с приемом в эппловский апп-стор.

Последним был 
Руслан Мартимов (General Satellite) с докладом "Death march projects и развитее разработки в компании", рассказывал хоть и очевидные вещи, но вполне живо: придется рубить углы, команда важна, безнадежный проект - хороший повод посмотреть, где у вас узкие места, чтоб сделать работу эффективнее. Извлек из доклада спорную мысль "Deathmarch, как двигатель прогресса" =)

суббота, 18 февраля 2012 г.

От хорошего к великому. Почему одни компании совершают прорыв, а другие нет… / Good to Great: Why Some Companies Make the Leap... and Others Don't. James C. Collins

Год тянулась у меня эта книга (когда-то бросил, т.к. не нашел чего-то сильно полезного и нового, но таки решил добить после рекомендации в "Четыре шага к озарению".

С одной стороны книга специфичны типа: как хорошие компании превращаются в великие.
Под хорошими подразумевается x% доходность выше рынка, под великими - в разы большая рынка доходность и рост в течении последних 10 лет. Для чистоты эксперимента брались компании-побратимы, которые так и не стали "великими", и смотрелось что делали 1ые, но не делали вторые.

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

Еще интересные факты: в результате кризисе 2008 года, одна "великая" компания разорилась(Circuit City Stores), а Wells Fargo потребовалось займов на 25 миллиардов доллар, чтоб остаться на плаву, Gillette был выкуплен Proctor & Gamble,  Fannie Mae была замешена в скандале с ипотечными облигациями  =)

В общем прочитать можно, т.к. авторы проделали реально много работы чтоб создать этот труд, но можно принимать его с некой долей скептицизма)

7 принципов великой компании:
1) Лидер "5го уровня"(CEO). Если честно я не запомнил описание конкретно всех уровней (и даже не уверен, что они были =)), но общая идея 5го такова: скромный человек с профессиональной волей сделать свою компанию великой, который ставит долгосрочное процветание компании превыше всего (и в частности - краткосрочных своих собственных прибылей), в частности он должен быть повышен из собственной компании а не привлечен со стороны.
Взять по этой же книги например Стив Джобс ни разу не лидер 5го уровня, т.к. без него компания чуть ли не развалилась, и не факт, что после его смерти она будет такой же успешной, но то влияние, что он сделал пока был ее лидером, так и останется с нами: планшеты, ифоны, тач-слайд-интерфейсы и т.д., спорный пункт.

Книга честно признается: а хрен его знает как определить таких лидеров, но они есть. =)

2) Сначала наберите к себе в команду гениальных людей, а потом уж решайте куда двигаться.
Стандартное "Кадры решают все", сомневаюсь, что хоть одна компания намеренно набирает некачественные кадры. Довольно банальный принцип.

3) Столкните нос к носу с проблемами и возьмите в привычку за ними наблюдать, а не игнорировать. Научитесь принимать их насколько все плохо бы не было, но не теряйте надежды. В общем-то методология Лина, CMMI и т.д., которая подразумевает, что столкнувшись с проблемой вы перестроите свой бизнес\производственный процесс, чтоб убрать ее.

4) Принцип "ежа" (hedgehog concept), раньше часто слышал, но видимо эта книга откуда он действительно пошел. Идея в двух типах: "лисицы" vs "ежы" , лисы все делают понемногу, но не отлично, а ежы - что-то одно, но отлично. Ну и бытие ежом выгоднее, т.к. позволяет сфокусироваться на том что: приносит деньги, удается лучше всего и приносит удовольствие\мотивирует. В общем-то какой именно принцип (делаем много маленьких доступных магазинов, развиваем широкую сеть финансовых услуг) не важно, т.к. главное его иметь и следовать ему, а не каждые год-два менять вектор своего развития.

5) Принципе взращивание "культуры дисциплины": люди принимают на себя обязательства и они вольны в выборе средств их достижения, но обязаны приложить все усилия чтоб их достигнуть. В общем-то взращивание идеальных работников\коллег - попросил, они назвали срок и сделали, к этому сроку, а не ленились, тупили, "это не моя ответственность" и т.д. В общем в компании должно быть развитое GTD и ответственность)

6) Использование технологии для ускорения развития. Тоже довольно банально =) Если вы растете, то используйте технологии, чтоб увеличить рост по пути вашего "ежьего принципа". Технология не поможет вам стать хорошим, великим и вобще "спасти", но она может ускорить рост.

7) Усиливайте инерцию: множество маленьких инициатив направленных в одно русло в итоге, приведут к созданию скорости и ускорения. Т.е. ваша компания будет набирать инерцию, как снежный ком, и постепенно будет катиться уже сама без ваших постоянных усилий.

Итого: книгу можно было б и уменьшить в пару раз, мне пришлось заставить себя добить ее, была б в 2 раза меньше прочиталась б быстрее, в целом идее вроде не плохие, но книга сейчас уже по устаревшим данным и не все ее компании оказались такими уж "великими". В целом интересные мысли есть, но если бросить все и начать применять эти принципе не факт, что станет лучше =)

четверг, 15 декабря 2011 г.

Прослушал аудиокнигу "Мифы о коммуникациях"

Очередная книжка о том, как общаться, верней о том, как мы воспринимает общение, и как оно есть на самом деле)

Очень короткая книжка (всего-то минут 50), помнится прослушал ее за 1 день пока шел на работу (да и вобще больше на статью тянет, чем на книгу), и пока шел с нее, потому в принципе ее не составит труда осилить даже тем, кто вобще не читает\слушает книги =)
Даже чувствую некоторое недовыполнение плана по прочтению книг на этот месяц, думаю осилю еще что-нибудь до конца года =)

В книжке перечислены 6 мифов, когда мы уверенны, что доносим до собеседника именно, то что думаем, а не то, что говорим)
И почему-то не сомневаемся, что он воспримет через призму собственного настроения,
опыта и отношения к нам, именно то что мы хотели сказать:
Что ,сказав девушке "ягодка, моя" - она не ответит нам: "а за `арбуз` ответишь!".
Что промолчать - это тоже коммуникация, только мы сообщаем- "ты мне не интересен, мне пофиг на тебя".
Что войдя в комнату к боссу со своим супер-предложением после того, как он отчитал другого своего подчиненного мы выйдем победителем, а не нарисуем на своем собственном лбу мишень)
Да и просто о том, что человек слышит нас. а не то что он хочет услышать =)

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

Ссылка на озон: http://www.ozon.ru/context/detail/id/3411517/ (хотя, в гугле довольно легко находятся и бесплатные аналоги)

Спасибо за потраченное время и читайте книги =)

воскресенье, 4 декабря 2011 г.

"Harvard Business Review" / Ведение переговоров и разрешение конфликтов.

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

Данная книга - выборка из 8 статей по тематике переговоров:
1)"Урегулирование разногласий" Роберта Танненбаума и Уоренна Шмидта
2)"Команда, которой не было" Сюзи Уэтлауфер
3)"Как пожить конец войне группировок" Роберт Блейк, Джейн Моутон
4)"Переговоры с клиентом, которого нельзя потерять" Томас Кайзер
5)"Как превратить искусство ведения переговоров в корпоративный потенциал" Дэнни Эртел
6)"Анатомия конфликта между клиентам и консультантом"  Айделин Кейснер
7)"Пять способов не довести дело до суда" Джон Эллисон
8)"Альтернативное разрешение споров: почему в одних случаях оно результативно а в других - нет?" Тодд Карвер, Альберт Вондра.

Первая статья наверно классика разрешения конфликтов в коллективе и про способы управления ими, что-то вроде теоретического обзора на практическом примере(отдалено похоже на тренинги Орлова и Панкратова про разрешение конфликтов).
Рассказывает про этапы развития, способы его разруливания и о способах принятия решений. Только если консультанты сразу говорят "превратите конфликт в решение проблемы", то книжка честно говорит - нет времени\желания разрешать конфликты в коллективе - так предупредите их (нанимайте похожих людей, чтоб они не спорили) или подавляйте их или даже может быть обостряйте их, чтоб узнать что-то новенькое. Не пожалел, что прочитал и думаю еще пригодиться в жизни.

Вторая статья это рассказ о классическом случае попытки создания команды из людей, не все из которых привыкли работать в команде. С наличием "ковбоя-суперзвезды" по совместительству, как раз не командного игрока. Довольно типичный случай только для сферы бизнеса, а не ИТ. Довольно неплохо обмусолено в книжках по командообразованию или например Архипенко.

Третья статья это тоже довольно классическое "разработчики vs тестировщики" либо "разработчики vs продажи" и т.д., которое тоже обмусоливается из года в год и на каждой конференции и в каждой итшной группе на фейсбуке (кажется было буквально месяц-два назад на agilerussia=)).
Только тут это подано в "индустриальной" форме: "менеджмент vs профсоюзы" и "конструкторское бюро vs заводы".
В общем-то рецепты решения одинаковы для всех случаев: создания атмоферы открытости и доверия, последующего обнаружения, что точки зрения противоборствующих сторон, чуть ли не диаметрально противоположны. Ну и последующему снижению общей напряженности ситуации и созданию рабочей группы по разрешению конфликтов. Только тут могут быть два варианта: напрямую и через привлечение внешнего посредника, но лучше начать с первого, т.к. если привлечь посредника и переговоры провалятся, то второго шанса уже не будет, а если не получилось напрямую, то можно попробовать еще раз через посредника.

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

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

Шестую статья достаточно специфична потому ее описания я пропущу, потому как название говорящее, а пригодиться она может лишь малому количеству людей.

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

В сша есть отдельные институты, которые позволяют снизить нагрузку на судебную систему и затраты на обслуживание судебной системы, путем обращения например к судьей в отставке(если все стороны согласны на это) и при этом его решение имеет, такой же вес, как и решение действующего судьи.
Не уверен на сколько, это применимо в нашей стране: договориться или решить через суд, что применяют иностранные,а что наши компании.

Последняя статья рассматривает в каких случаях АРС, как раз не работает: не согласие одной из сторон на его самый, низведение его до псевдо-судебного процесса с доказательствами, адвокатами и прочим и т.д. Думаю сам АРС пока слабо применим в Российских реалиях, потому не буду раскрывать эту статью подробно.

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

среда, 30 ноября 2011 г.

Отчет об посещении питерской SpmConf.


В прошедшую субботу (26 ноября) состоялась Software Project Management Conference. И прошла удачно) С кучей маститых и известных докладчиков, и парой-тройкой знакомых по твиттерам-блогам лиц)

Да и прошла для разнообразия не в Москве, а в Питере, что тоже по своему хорошо =) Своеобразный город, где еще люди, еще отмечающие пятницу, с утра субботы в баре угостят кофе (рано приехал к 6-7 к отелю и потому зашел в ближайшую по гугл-мапс кафе\забегаловку, где люди пили коньяк\пиво и играли в шахматы=)). А встречающаяся вечером пьющая алкоголь школота обсуждает Шопенгаура и поэзию 15 века =)

Вернусь к докладам и мои впечатлениям от конференции.

Заранее сразу вычеркнул из списка на посещение доклады Архипенкова, т.к. они в принципе повторяют его же книгу + когда-то на одной из работ мы приглашали его на целый день почитать свои доклады), так что ничего нового я и не рассчитывал узнать).

Начал с прослушивания доклада по результатам ежегодного исследования индустрии разработки ПО Валентина Макарова.
С одной стороны было интересно узнать, что вливания в ит внутри России прямо сопоставимы тренду цены на  нефть.
С другой докладчик, как-то честно рассказал, что растем мы не быстрее других стран BRIC`а в последние года даже чуть медленнее, что государству на Ит особо наплевать и вобще ситуация  в целом довольно грустная.
Думаю владельцам и работникам аутсорсеров и интерграторов данный доклад показался и покажется интересным)

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

Пошел послушать Максима Вишневского про отдельные вопросы анатомии менеджера, он рассказывал какие факапы и ошибки совершал в своей бурной пм-молодости, как переносил сроки проекта по 4 раза =) Переписывал проекты с нуля и все такое) Слушать развлекательно и забавно , но каждый в душе надеяться, что такие уж ошибки он то и не совершит) Хотя с другой стороны в конце доклада вышло, что совершить ошибки это хорошо - начинаешь понимать, что и где может пойти не так, приобретаешь опыт)

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

Потому пошел послушать Серегу Бережного, вот уж кто раскрутился и стал вполне себе известной в ит личностью за последний год =)
Доклад был о переносе сроков, то что достаточно актуально для любого более-менее длинного проекта со сроками) Был дан универсальный совет, что сроков то лучше не иметь вобще, но уж если они у вас есть то извольте их контролировать и уметь вовремя изменить. 
Не буду дословно пересказывать, т.к. он уже выложил свою презентацию.

После Сергея краем уха послушал Вячеслава Нестерова (Генеральный Директор Санкт-Петербургского Центра Разаботки EMC), который рассказал, как их корпорация подходит к развитию своей инновационности, т.к. чувствует, что без инновационности - можно и отстать от конкурентов.
И поэтому докупает компании занимающиеся разработками продуктов на рубеже неизведанного (типа VmWare), и всячески поощряет коммуникацию и обмен знаниями среди своих подчиненных/
Круто, что большие корпорациии вобще задумываються об этом, с другой стороны доклад тоже достаточно специфичен и был бы интересен узкой категории, тех кто работает в похожих по размерам и глобальности компаниях)

Потому с его доклада я ушел слушать Михайла Ганчикова про развитие проекта в условиях нулей видимости)
Это когда есть сроки когда все должно быть готов и больше никаких знаний, что же придеться делать, т.е. требований на момент старта проекта не предполагается и точно известно, сто функционал из требований выкидывать не позволят =)
Вобще доклад довольно классно прошел, практически по идеальной схеме - объяснение проблемы - нагнетение обстановки - кульминация, прям как по книжке)

В кратце отмечу, что почерпнул пару интересных мыслей, работали они по скраму и в итоге как решение своих проблем выбрали постепенное наращивание команды, чтоб выйти на заданную производительность по мере оценки и переоценки задач и чендж-реквестов) + у Них был такой интерсный момент, как "Технический продукт овнер", эдакий архитектор в скраме, задачей которого было договариваться с заказкичом, как облегчить и сделать легче функционал в рамках разработанной архитектуры.

Потом пошел слушать Михайла Завилейского из DataArt`a: сначала был небольшой скептицизм из-за очень уж "боянных" тезисов в программке типа: почему заставлять коллег соревноваться плохо.

Датаарт похоже своеобразная компания, т.к. управляется эдакой массовой рассылкой на 28 человек(топ-менеджмента), без какого-то особого лидерства и руководства, как говорил сам Михайл он бы сам не поверил, что такое работает, если бы не видел это в живую.

Если во многих книгах про великие компании говориться, что чтобы стать великими вам надо иметь принципы\миссию\вижен, то они действуют от обратного - никаких особых принципов (кроме никто не должен выполнять бесполезной работы): все вольны иметь свои убеждениям, главное толерантно к друг-другу относиться и это работает).
Т.к. на рынке, где кандидатов на работу мало, компании с особой политикой и принципами вынуждены отсеивать не подходящих им людей, а Датаарт спокойной набирает их и растет, то их позиция - намного выгоднее.
Было рассказано про то, что кнут в общем-то не всегда работает, как задумано: если у человека есть возможность заплатить штраф например за опоздания и он не слишком большой, то вы фактически даете ему возможность купить индульгенцию, т.к. штраф он вроде как заплатил и журить после этого за опоздания его уже глупо)
Повторил довольно известную мысль, что в общем-то KPI ведут к оптимизации KPI и скорее всего приведут к "игре" - "мы играем по таким то правилам, мои KPI упадут, если я тебе помогу так что - пока" =)
В общем доклад навел на 10к-другой полезных мыслей =) Прослушал с удовольствием наверно  и засчитал бы его в топ-3 по всей конференции)

После был обед в который ел и обсуждал с знакомыми людьми, что к чему и где-что было интересно)

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

После волны не особо интересных докладов, пошел слушать Григория Печенкина  об "Культурных различиях в IT", в общем-то обзорно прошлись по разным полюсам типа доверия\паранои, команда\лидер и т.д. Как обзорный доклад может и хорош, но какую-то финальную  мысль, кроме того, что вот мол бывает так и сяк я не особо уловил. Тролль-команда в лице Михаила Заборова из Custis`а и еще пара человек, задавала каверзные вопросы, чем слегка оживила его дискуссией в конце и показала наличие московской тролль-культуры =)

Параллельно чуть послушал Ольгу Павлову из UsabilityLab, которая успешно развенчивала мифы о том, что Hr`ы важны и нужны(от коих на конференции было минимум 3 доклада, на которых они активно рассказывали почему не надо искать самому, а надо юзать их способности ) и нужны и рассказывала, как самим набирать программистов, менеджеров и прочих итшных личностей. Помню, что было вполне интересно и докладчица рассказывала в меру живу и интересно и даже приводила свою собственную систему hr-стайл GTD по найму.

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

один из этапов развития
матричной структуры
Что рано или поздно наличие матрицы и оптимизация ресурсов приведет к занятости 1,5 землекопа на проект, что крайне не эффективно и итогом этого развития, как не странно видятся готовые самоорганизующиеся кросс-функциональные команды (Внезапно, да ?)) =)

Было интересно послушать, как некоторый такой экскурс в историю, увидеть и понять как оно идет в типичном аутсорсере.
И тлеяла надежда узнать, что же там - за следующем level up`ом, но она не оправдалась)

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

После кофе-брейка был мастер-класс Дмитрия Башакина о донесении обратной связи до подчиненных, разобрали, на первых участниках разобрали какие ошибки может совершить PM, что может ему помешать эту самую связь донести и вобще-то рассмотрели детально, что делать, чего спрашивать и чего и кому показывать=).

Но гораздо интереснее были вторые участники в качестве "провинившегося сотрудника" выступил 1 из участников мастер-класса которые был настроен жестоко повоевать, перебивал пма, мастерски отмазывался, не хотел давать никаких обещаний, переносил разговоры на потом и т.д. Cотрудник-тролль-звезда в одном лице заставлял заливатсья хохотом весь зал так мастерски он уходил от ответственности и ответов на вопросы)
В итоге сам Дмитрий Башакин хотел показать, как надо доставлять обратную связь, но был им успешно затроллен в том числе =)
После по горячим следам разгорелась мини-дискуссия о том, что чтоб сотрудник мог вести себя ТАК, он либо должен быть незаменим либо сразу же уволен)

Предпоследним слушал доклад Дмитрия Безуглого про лестницу работы с потребностями потребителей, в какие-то идеи этого доклада я видел еще на ЛАФ`е (Летний Аналитический Фестиваль) и потому информация не была для меня совершенно новой.
Дмитрий разрабатывает свой фреймворк для создания продуктов для потребителей на основе идей Design Thinking собственного опыта и т.д. Цель которого создавать такой продукт, который может не только показаться интересным потребителю на неделю чтоб поиграться и уйти к конкуренту, но и чтобы покрыть его скрытые потребности типа ощущения себя себя избранным от работы с вещью, а не только от выполнения ею базовых полезных функций.
Довольно тяжело сформулировать всю концепцию словами, но будем надеяться видео с конференции появится в ближайшем будущем. Думаю доклад был бы интересен product менеджерам.

Вместо последних докладов пошел слушать стендовый доклад Стаса Фомина об Humanized Software Development, единственное о чем я жалею на этой конференции - что не пошел слушать его раньше, а успел лишь на последнюю треть, т.к. себя Стас не записывал =).

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

Стиль Стаса не передать словами, это эдакая веселые откровения наполненный глубокомысленной философией =) Надеюсь, что когда нить я все таки наткнусь на полную версию его доклада и посмотрю =)

В общем было кого послушать, о чем подумать и где пожалеть, о том, что не смог разорваться на 3 части.
Из проблем конференции - довольно насыщенная программа, так что многие вопросы докладчику приходилось пропускать, т.к. было мало времени на ответы, думаю конференции без проблем могла бы растянуться на два дня с более расслабленным таймингом докладов и было б еще лучше =)

Спасибо, что дочитали до конца, удачного вам дня. Увидимся на следующей #spmconf !

воскресенье, 13 ноября 2011 г.

Презентации, как Стив Джобс.

Как сделать вот такую презентацию.
Как-то так получилось, что добрался до чтения этой книги(Секреты презентаций Стива Джобса, Кармин Галло) только после смерти самого Джобса.

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

Не буду пересказывать книгу, т.к. лучше 1 раз увидеть, чем 100 раз услышать =) Лучше сразу расскажу почему и чем она была интересна.

Почему книгу стоит прочитать
Как только вы поднялись на одну ступень со дна, 
ваша эффективность зависит от способности
 достигать умов других людей 
с помощью письменного и устного слова.
Питер Друкер
Мы можем не знать насколько сильно Стив Джобс влиял на сущность и удобство программ и устройств, которые производит эппл(кроме него там все таки работают и работали тысячи других инженеров\дизайнеров\менеджеров и т.д). 
Но по презентациям видно, что презентовать свой продукт и продавать его так хорошо, чтобы любителе бренда стояли в очередях и ждали его он умел. Даже Билл Гейтс и любой другой CEO за всю историю ИТ не был такой иконой, как Стив Джобс и дело не только в продуктах, дело в том как он преподносил себя и свою компанию.

Думаю и вам хочется, чтобы:
ваш продукт покупали 
или готовы были "купить" вас самих при собеседовании (умение договариваться уже практически требование в менеджерских и ИТ-вакансиях)   
или чтобы ваши идеи находили отзыв в сердцах коллег и клиентов,
или хотя бы уметь проще и понятнее донести свои мысли до окружающих. 

Почему если хоть один из этих вопросов вас волнует и вы еще не уверены, что способны сделать презентацию круче чем Джобс - то эта книга для вас.


Этот парень, что-то знает.
Что в книге хорошего
Интерес. 
Ее интересно читать, видно, что автор сам воспользовался теми советами, что приводил. Ее чтение идёт прямо, как захватывающее художественное произведение.
К примеру часть книг, что я читаю, приходиться планировать в стиле "прочитать еще 50 страниц из книги Х со страницы Y"(на самом деле), т.к. они довольно скучно изложены и хотя и полезны, но могут быть только вот таким поеданием слона по кусочкам.

Эта же книга - из "прочитать 100 страниц" превратилась в "все таки оторваться от нее и сделать остальные дела из списка" =)
Множество историй из жизни, сравнения с другими известными ораторами, даже черт возьми статистика используемых слов показывает, как и почему Джобс делал такие успешные презентации.В общем - цепляет!

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

  • задумка
  • планирование
  • подготовка и приукраска
  • выполнение
  • "holy shit" момент, когда пользователь понимает - вот она рыба моей мечты гениальность этой идеи!
  • получить удовольствие 

Выполнить - отрефлексировать и отточить - повторить - профит =)
Что, где и как - написано с примерами, цитатами, в общем вы гарантированно запомните, в книжке даже есть пример для 1го из пунктов - "как бы я написал отзыв на эту книгу". 
Отзыв мне понравился - сразу захотелось прочитать книгу, а потом скопировать в блог =)

Простой деревенский парень - Стив
Простая и понятная.
В общем-то книга тоже следует заветам Джобса.
Никаких экскурсов в историю когнитивной психологии, мудреных терминов -  все рассказано простыми человеческими словами)

Ну и финальная цель выступления и самой презентации обозначена просто = "have fun" - получайте удовольствие от процесса!

Так и я пожелаю вам получить удовольствие от книги и от ваших будущих презентаций, таких же успешных, как у Джобса =)

P.S.
Краткий пересказ в слайдах книжки можно увидеть тут: презентация на слайдшаре (на английском) 
Иди и прочти!

понедельник, 10 октября 2011 г.

Обзор книги Эрика Берна "Лидер и группа. О структуре и динамике организаций и групп"

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

Если имя автора вам ничего не говорит, то можно загуглить "транзакционный анализ" и "родитель-ребенок-взрослый". Узнаете кое-что полезное =)

Не смотря на наличие у меня некоторые знаний о динамике командо-образования, данный труд показался мне гораздо более глобальным и фундаментальным с одной стороны и гораздо более сложным теоретически с другой.

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

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

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

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

Если по прохождению тренинга по командообразованию, мне было известно о двух типах руководителей "администратор" & "лидер", то теперь узнал что их 3:
  • эффективный лидер - "доминирующий и влиятельный"
  • ответственный лидер - "тот, кого призывают к ответу "
  • психологический лидер - "первый после бога =)" - всемогущий, всезнающий и гениальный - в общем, как Стив Джобс для Эппла =).  
В общем почвы для размышлений можно понабрать на месяц-другой =)

Вся вторая часть книги посвящена тщательному(реально тщательному, но в то же времени сложному и слегка нудному =)) анализу одной группы, о выделении в ней лидеров, о борьбе и основании в ней границ, о внутренних процессах борьбы и давления и т.д. Группа довольно специфична  - "спиритическая", потому какие-то конкретные примеры и кейсы сложно применить к повседневной жизни, вот так сразу но некоторую отшлифовку книжной теории на ней можно понять.

Третья и четвертая часть книги посвящена анализу индивида в группе(его потребностей, транзакций и игр) и прикладной социальной психиатрии, знание из которых может и было бы полезно просмотреть, но они уже скорее идут к чисто таким психиатрским скилам, что если честно в рамках расширения кругозора я бы посчитал овер-киллом =)

Итого: первую часть можно и нужно почитать, вторую чтоб на практическом примере понять как же оно работает, и получить в голове пару озарений в стиле "ага, вот оно что!", а третью и четвертую - только если вам реально интересно и есть свободное время =)