|
|
By Konstantin Bychenkov, on January 2nd, 2012
или как нанять менеджера проектов
Когда-то я написал статью о том, что должен выяснить для себя соискатель, устраивающийся на вакансию менеджера проекта- «Абсолютный минимум для новой жизни». Но все меняется. В связи с расширением количества проектов начал подбирать кандидатуры менеджеров и взглянул на проблему «с другой стороны баррикады». Столкнулся сразу с двумя проблемками:
- как сформулировать требования к кандидату?
- как проверить соответствие кандидата требованиям?
С программистами все более-менее понятно: предложил тестовое задание, провел интервью на интересующие области знаний, прощупал личные качества и стремления — и принимай решение. Профессия программиста одна из самых «честных», навыки легко измерить.
Continue reading Куплю мозг
By Konstantin Bychenkov, on October 22nd, 2011
В этом году я буду делать доклад на конференции «Разработка ПО 2011» CEE-SECR 2011
Немного о докладе.
Управление изменениями является одним из важнейших аспектов управления проектами и управления вообще. Но при этом часто забывают об изменениях, которые происходят с людьми. Часто мы забываем, что человек не все время один и тот же. Все люди меняются, в том числе и на работе. Вместе с ними меняются команды и коллективы предприятий. Перемены могут быть не всегда к лучшему. Ко переменам нужно быть готовым. Для успешной работы на всех уровнях нужно понимать закономерности и возможности на каждом этапе. Люди на разных уровнях ответственности часто не понимают друг друга. Их ожидания бывают противоположными. Это приводит к разочарованиям и в итоге, потере цели коллективом компании. Это удивительно, потому что фирма-то – маленькая, в ней по определению проще достичь понимания и устранить проблемы на ранней стадии.
Спектр SME компаний многообразен, в своем докладе я коснусь фирм, которые:
- Ограниченны в возможности по привлечению ресурсов извне. Ресурсов просто на всех не хватает.
- Росли «с нуля». Сначала появилась фирма – потом деньги.
- Коллектив образовался как «рыцари круглого стола».
Мы рассмотрим взаимоотношения сотрудника и компании в следующих аспектах:
- Жизненный цикл организации подразделения и сотрудника.
- Взаимные ожидания сотрудников фирмы в зависимости от занимаемых ими позиций.
- Работа в условиях турбулентности жизненных циклов фирмы, подразделений и сотрудников.
Надеюсь, что после моего рассказа некоторые люди лучше смогут ответить себе на вопросы:
- Чего я хочу добиться на своем рабочем месте?
- Как мне найти союзников по достижению профессиональных целей?
- Чего от меня еще хотят, я же делаю свою работу?
Примерно так, приходите на SECR2011, буду вам очень рад.
http://www.secr.ru/lang/ru-ru/talks/company-employee-relationship-in-sme
By Konstantin Bychenkov, on September 5th, 2011
Однажды, давным-давно, я пришел работать программистом в одну маленькую самарскую фирму, которая оказывала услуги офшорного программирования для рынка США. Россию в то время захлестнула волна Delphi проектов по автоматизации всего-всего. Телекомы, торговля, нефтедобыча, ERP. А тут я в другой мир попал, проекты могли быть о чем угодно. Как говорил директор – “Если нам завтра заплатят за проект на ЕС-ках – мы притащим ее с помойки советского НИИ и поставим в центре офиса”. Мне поручили программирование мобильных устройств, которых я до той поры и в руках не держал.
В общем, я попал в хорошие руки. И дело было не только в технике. С техникой все было сравнительно просто – было много литературы и много готовых проектов. Когда мне что то надо было узнать – я находил проект, в котором решалась аналогичная задача и человека, способного прояснить ситуацию. Работая над проектами я знал, что за люди мои заказчики, откуда они родом, чего ждут от нас, чего мы ждем от них, каков стиль работы и общей уровень их бизнеса, как с ними следует общаться. В общем – много всего, чего мне могли бы и не говорить. Мой менеджер оказался тем, что мне было нужно. Это и определило мою дальнейшую успешную работу. Я не просто старался сделать все, что в моих силах. Я знал производственный контекст, в котором я работал.
Continue reading Knowledge Management – я знаю, что вы знаете, что я знаю
By Konstantin Bychenkov, on May 28th, 2011
Будешь злым – повесят, будешь мягким – раздавят
(Татарская пословица)
С возвращением в мир проектов заказного ПО! Итак, конкурс выигран, контракт заключен, и мы продолжаем. То, что коммуникации — наиболее вероятная причина бед менеджера проекта, стало уже общим местом книг и статей по управлению проектами. Оно и так понятно. В конце концов ради коммуникаций менеджера проекта и нанимают. Из-за коммуникаций горят карьеры. Что же нам нужно, для того чтобы успешно наладить обмен информацией внутри команды и со всеми заинтересованными сторонами? Конечно, нам нужен план коммуникаций. И не говорите, что вам некогда сделать такой план. Вы же менеджер, у вас всегда есть план. Вы заранее должны подумать что, кому в какой форме и когда вы будете сообщать, а что — спрашивать. Остается только изложить этот план в документ, выделить в нем публичную часть и разослать всем заинтересованным сторонам.
Continue reading Еще несколько штрихов к плану коммуникаций
By Konstantin Bychenkov, on May 12th, 2011
Если кто то решил, что я свой блог совсем забросил – таки нет! Просто было много дел, а еще мы с Александром Калугиным организовали встречу менеджеров проектов по разработке ПО. Вот протокол в моем исполнении:
http://pmsamara.blogspot.com/2011/05/blog-post_11.html
Следите за новостями!
By Konstantin Bychenkov, on March 13th, 2011
«Why so serious?» (Joker)

Кто же не любит давать советы новичкам?! Или сидя в лодке, подальше от берега, кричать неуверенно стоящим на берегу пловцам «Ну чего вы там?! Плывите сюда!» Выпимши 100 грамм настойки, «для куражу», хочу продолжить дело, начатое Сашей Калугиным в его статье «Менеджер-начинашка». Какие мысли хорошо бы чтоб пришли в вашу голову в начале пути?
Continue reading Для тех, кто впервые на родео
By Konstantin Bychenkov, on March 6th, 2011
Как то мне в голову пришло посчитать как изменялось соотношение стоимости команды к количеству сделанной работы на протяжении двух с половиной лет. Итоги меня в целом порадовали — стоимость разработки одной истории за указанный период упала в среднем в два с половиной раза. Во многом мне помог и довольно низкий старт, но все таки. «Вот она, эффективность» сказал себе я и, довольный, набрал в поисковой системе «team effectiveness in IT’» чтобы посмотреть, а что же вообще в мире то делается на тему эффективности. Continue reading Эффективность команды. 1 пишем–2 в уме
By Konstantin Bychenkov, on January 16th, 2011
Самара — город маленький. Все друг с другом знакомы и одни и те же люди переходят с одного рабочего места на другое, пока не найдут себе гавань по душе.
-А Федя у вас сейчас над чем работает? — спросил я друга, после того как мы поставили на стол кружки с пивом. Федей гордились в фирме.
-Ни над чем. Последнее время от него получали отговорки вместо результата.
-Интересно, почему? Он был клевый… Вы и платили ему хорошо.
-Был, но так со всеми бывает, как поломался.
Я согласно кивнул и сделал большой глоток. Такие истории меня уже давно перестали удивлять.
Мотивация — то, что нужно нам всем. «Труд станет потребностью!» предсказывали классики марксизма. Время показало, что это скорее заклинание вуду, чем научный факт.
Continue reading Мотивация. Нам не все равно!
By Konstantin Bychenkov, on December 26th, 2010
Эта статья является продолжением нашего с Александром Калугиным спора о том, чем должны заниматься специалисты QA\QC в небольших проектах.
Я кажется уловил суть нашего спора. Мы с Александром по разному смотрим на шансы, которые команда может использовать в достижении успеха проектной деятельности.
Continue reading Дай качество! Шанс, он не получка не аванс.
By Konstantin Bychenkov, on December 15th, 2010
 На последней конференции ETalks QA 2010, которая была посвящена «контролю качества программного обеспечения и всему, что с ним связано», в конце было выступление Александра Калугина. Это выступление переросло в круглый стол, который перерос в afterparty и продолжился уже в такси по дороге по домам. Речь зашла о том, что должен делать по настоящему полезный QA-отдел для общего успеха. Спецам по качеству было предложено обосновать свое существование. Также было сказано, что одного тестирования не достаточно. Ну, пусть лучше Александр сам расскажет в своем блоге.
На самом деле, QA бывает и правда трудно объяснить, за что ему платят. Как говорил один выдающийся борец за качество — «У каждой ошибки есть имя, отчество и фамилия». Это действительно так, но означает ли это, что для обеспечения качества достаточно подобрать правильные кадры? Тот же самый борец за качество утверждал — «Кадры решают все!» Тогда можно будет забыть про тестирования от билда к билду, процессы QC, их аудит и кстати еще многое другое, что в том же CMMI описано. Было бы здорово! Тут должны обрадоваться те парни, что вложили в фирму деньги и очень не любят платить налоги с ФЗП.
На деле всем так повезти не может. Проверка соответствия продукта и спецификации требований (то есть, проверка качества) часто является очень трудоемким процессом и требует такого же внимания и сосредоточения, как и работа, например, аналитика. Это становится непрерывным процессом, которому нужны люди.
Можно обратиться к признанным мастерам качества — японцам, и их идеологии « кайдзен». Там есть несколько замечательных принципов. Нам особенно пригодятся следующие два:
Встраивай качество в процесс как можно раньше (Качество должно встраиваться в процесс, проверка не создает качества)
Придерживайся концепции «ориентация на рынок» (Клиент прежде всего. Тот кто выполняет следующую технологическую операцию — твой потребитель.)
Да, качество достигается не просто тестированием. Но вот именно от QA я, как их заказчик, прежде всего жду качественной проверки соответствия требований и продукта. Мнение QA о том, что «когда-то так мы уже делали и это не понравилось» мало интересуют. Замечания о былых недочетах в архитектуре и потенциальных проблемах в производительности меня интересуют немного более. Только это все есть в отчетах о тестировании, если они хорошие. Так что все эти выводы и без участия QA есть кому делать. QA должен быть профессионален в своей области и будет с него. Грамотные запросы к аналитикам и отчеты разработчикам — этого достаточно. Да, при таком подходе QA превращается во вспомогательную службу, а это всегда объект для экономии. Да, тут мало сотрудничества и team spirit.
Я в течение своей карьеры не очень-то уверовал во взаимовыгодное сотрудничество внутри коллектива и считаю, что за интеграцию должны отвечать специальные люди. А вот тем, кто просто хорошо делает свою работу, я очень благодарен. Это пока еще такая редкость.
|
|
Recent Comments