January 2012
M T W T F S S
« Oct    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Куплю мозг

или как нанять менеджера проектов

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

  • как сформулировать требования к кандидату?
  • как проверить соответствие кандидата требованиям?

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

Continue reading Куплю мозг

Взаимоотношения сотрудник-фирма в предприятиях масштаба SME

В этом году я буду делать доклад на конференции «Разработка ПО 2011» CEE-SECR 2011

Немного о докладе.

Управление изменениями является одним из важнейших аспектов управления проектами и управления вообще. Но при этом часто забывают об изменениях, которые происходят с людьми. Часто мы забываем, что человек не все время один и тот же. Все люди меняются, в том числе и на работе. Вместе с ними меняются команды и коллективы предприятий. Перемены могут быть не всегда к лучшему. Ко переменам нужно быть готовым. Для успешной работы на всех уровнях нужно понимать закономерности и возможности на каждом этапе. Люди на разных уровнях ответственности часто не понимают друг друга. Их ожидания бывают противоположными. Это приводит к разочарованиям и в итоге, потере цели коллективом компании. Это удивительно, потому что фирма-то – маленькая, в ней по определению проще достичь понимания и устранить проблемы на ранней стадии.

Спектр SME компаний многообразен, в своем докладе я коснусь фирм, которые:

  1. Ограниченны в возможности по привлечению ресурсов извне. Ресурсов просто на всех не хватает.
  2. Росли «с нуля». Сначала появилась фирма – потом деньги.
  3. Коллектив образовался как «рыцари круглого стола».

Мы рассмотрим взаимоотношения сотрудника и компании в следующих аспектах:

  1. Жизненный цикл организации подразделения и сотрудника.
  2. Взаимные ожидания сотрудников фирмы в зависимости от занимаемых ими позиций.
  3. Работа в условиях турбулентности жизненных циклов фирмы, подразделений и сотрудников.

Надеюсь, что после моего рассказа некоторые люди лучше смогут ответить себе на вопросы:

  1. Чего я хочу добиться на своем рабочем месте?
  2. Как мне найти союзников по достижению профессиональных целей?
  3. Чего от меня еще хотят, я же делаю свою работу?

Примерно так, приходите на SECR2011, буду вам очень рад.

http://www.secr.ru/lang/ru-ru/talks/company-employee-relationship-in-sme

Knowledge Management - я знаю, что вы знаете, что я знаю

Однажды, давным-давно, я пришел работать программистом в одну маленькую самарскую фирму, которая оказывала услуги офшорного программирования для рынка США. Россию в то время захлестнула волна Delphi проектов по автоматизации всего-всего. Телекомы, торговля, нефтедобыча, ERP. А тут я в другой мир попал, проекты могли быть о чем угодно. Как говорил директор – “Если нам завтра заплатят за проект на ЕС-ках  – мы притащим ее с помойки советского НИИ и поставим в центре офиса”.  Мне поручили программирование мобильных устройств, которых я до той поры и в руках не держал.

В общем, я попал в хорошие руки. И дело было не только в технике. С техникой все было сравнительно просто – было много литературы и много готовых проектов. Когда мне что то надо было узнать – я находил проект, в котором решалась аналогичная задача и человека, способного прояснить ситуацию. Работая над проектами  я знал, что за люди мои заказчики, откуда они родом, чего ждут от нас, чего мы ждем от них, каков стиль работы и общей уровень их бизнеса, как с ними следует общаться. В общем – много всего, чего мне могли бы и не говорить. Мой менеджер оказался тем, что мне было нужно.  Это и определило мою дальнейшую успешную работу. Я не просто старался сделать все, что в моих силах. Я знал производственный контекст, в котором я работал.

Continue reading Knowledge Management – я знаю, что вы знаете, что я знаю

Еще несколько штрихов к плану коммуникаций

Будешь злым – повесят, будешь мягким – раздавят

(Татарская пословица)

comm_planС возвращением в мир проектов заказного ПО! Итак, конкурс выигран, контракт заключен, и мы продолжаем. То, что коммуникации — наиболее вероятная причина бед менеджера проекта, стало уже общим местом книг и статей по управлению проектами. Оно и так понятно. В конце концов ради коммуникаций менеджера проекта и нанимают. Из-за коммуникаций горят карьеры. Что же нам нужно, для того чтобы успешно наладить обмен информацией внутри команды и со всеми заинтересованными сторонами? Конечно, нам нужен план коммуникаций. И не говорите, что вам некогда сделать такой план. Вы же менеджер, у вас всегда есть план. Вы заранее должны подумать что, кому в какой форме и когда вы будете сообщать, а что — спрашивать. Остается только изложить этот план в документ, выделить в нем публичную часть и разослать всем заинтересованным сторонам.

Continue reading Еще несколько штрихов к плану коммуникаций

Первая встреча самарского сообщества менеджеров проектов

Если кто то решил, что я свой блог совсем забросил – таки нет! Просто было много дел, а еще мы с Александром Калугиным организовали встречу менеджеров проектов по разработке ПО. Вот протокол в моем исполнении:

http://pmsamara.blogspot.com/2011/05/blog-post_11.html

Следите за новостями!

Для тех, кто впервые на родео

«Why so serious?» (Joker)

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

Continue reading Для тех, кто впервые на родео

Эффективность команды. 1 пишем–2 в уме.

team effectsКак то мне в голову пришло посчитать как изменялось соотношение стоимости команды к количеству сделанной работы на протяжении двух с половиной лет. Итоги меня в целом порадовали — стоимость разработки одной истории за указанный период упала в среднем в два с половиной раза. Во многом мне помог и довольно низкий старт, но все таки. «Вот она, эффективность» сказал себе я и, довольный, набрал в поисковой системе «team effectiveness in IT’» чтобы посмотреть, а что же вообще в мире то делается на тему эффективности. Continue reading Эффективность команды. 1 пишем–2 в уме

Мотивация. Нам не все равно!

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

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

-Ни над чем. Последнее время от него получали отговорки вместо результата.

-Интересно, почему? Он был клевый… Вы и платили ему хорошо.

-Был, но так со всеми бывает, как поломался.

Я согласно кивнул и сделал большой глоток. Такие истории меня уже давно перестали удивлять.

Мотивация — то, что нужно нам всем. «Труд станет потребностью!» предсказывали классики марксизма. Время показало, что это скорее заклинание вуду, чем научный факт.

Continue reading Мотивация. Нам не все равно!

Дай качество! Шанс, он не получка не аванс.

Эта статья является продолжением нашего с Александром Калугиным спора о том, чем должны заниматься специалисты QA\QC в небольших проектах.

Я кажется уловил суть нашего спора. Мы с Александром по разному смотрим на шансы, которые команда может использовать в достижении успеха проектной деятельности.

Continue reading Дай качество! Шанс, он не получка не аванс.

Дай качество! Два мира–два Шапира

poster5На последней конференции ETalks QA 2010, которая была посвящена «контролю качества программного обеспечения и всему, что с ним связано», в конце было выступление Александра Калугина. Это выступление переросло в круглый стол, который перерос в afterparty и продолжился уже в такси по дороге по домам. Речь зашла о том, что должен делать по настоящему полезный QA-отдел для общего успеха. Спецам по качеству было предложено обосновать свое существование. Также было сказано, что одного тестирования не достаточно. Ну, пусть лучше Александр сам расскажет в своем блоге.
На самом деле, QA бывает и правда трудно объяснить, за что ему платят. Как говорил один выдающийся борец за качество — «У каждой ошибки есть имя, отчество и фамилия». Это действительно так, но означает ли это, что для обеспечения качества достаточно подобрать правильные кадры? Тот же самый борец за качество утверждал — «Кадры решают все!» Тогда можно будет забыть про тестирования от билда к билду, процессы QC, их аудит и кстати еще многое другое, что в том же CMMI описано. Было бы здорово! Тут должны обрадоваться те парни, что вложили в фирму деньги и очень не любят платить налоги с ФЗП.
На деле всем так повезти не может. Проверка соответствия продукта и спецификации требований (то есть, проверка качества) часто является очень трудоемким процессом и требует такого же внимания и сосредоточения, как и работа, например, аналитика. Это становится непрерывным процессом, которому нужны люди.
Можно обратиться к признанным мастерам качества — японцам, и их идеологии «кайдзен». Там есть несколько замечательных принципов. Нам особенно пригодятся следующие два:
  • Встраивай качество в процесс как можно раньше (Качество должно встраиваться в процесс, проверка не создает качества)
  • Придерживайся концепции «ориентация на рынок» (Клиент прежде всего. Тот кто выполняет следующую технологическую операцию — твой потребитель.)
    Да, качество достигается не просто тестированием. Но вот именно от QA я, как их заказчик, прежде всего жду качественной проверки соответствия требований и продукта. Мнение QA о том, что «когда-то так мы уже делали и это не понравилось» мало интересуют. Замечания о былых недочетах в архитектуре и потенциальных проблемах в производительности меня интересуют немного более. Только это все есть в отчетах о тестировании, если они хорошие. Так что все эти выводы и без участия QA есть кому делать. QA должен быть профессионален в своей области и будет с него. Грамотные запросы к аналитикам и отчеты разработчикам — этого достаточно. Да, при таком подходе QA превращается во вспомогательную службу, а это всегда объект для экономии. Да, тут мало сотрудничества и team spirit.
    Я в течение своей карьеры не очень-то уверовал во взаимовыгодное сотрудничество внутри коллектива и считаю, что за интеграцию должны отвечать специальные люди. А вот тем, кто просто хорошо делает свою работу, я очень благодарен. Это пока еще такая редкость.