Записи с метками команда
C Днем Тестировщика!!!
9 Сентябрь
Сердечно поздравляем всех тестировщиков с их профессиональным праздником!
Прежде всего хотелось бы пожелать взаимопонимания с остальными членами команды, руководством, коллегами. Было бы здорово, если бы истории о противостоянии программистов и тестировщиков остались в прошлом, если бы программисты всячески помогали тестировщикам в их нелегком труде, а менеджеры с пониманием относились к мнению тестировщика. Для этого нужно приложить немало усилий обеим сторонам, но все возможно.
Также хочется вам пожелать грамотных разработчиков, которые несут ответственность за созданный ими продукт. Ведь чаще всего именно из-за ошибок разработчиков прибавляется работы тестировщикам. «Воспитывайте» в своих разработчиках понимание качества продукта и все получится.
И, в заключении, желаем вам профессионального роста и раскрытия творческого потенциала. Ведь это то, для чего мы работаем в индустрии IT (кроме финансовой стороны конечно). Удачи вам в следующем профессиональном году!
Что же нас на самом деле мотивирует?
8 Сентябрь
Я не раз слышал споры по поводу мотивации сотрудников на различных конференциях и встречах. Приходилось сталкиваться с мнениями других людей на этот счет и на работе. Некоторые считают, что повышение зарплаты должно мотивировать сотрудника на отдачу в 100%. Другие говорят, что динамика зарплаты совершенно не влияет на мотивацию и нужно просто создать человеку комфортные условия работы. Я решил поделиться своим взглядом на вопрос мотивации.
Я являюсь сторонником двухфакторной теории мотивации Герцберга. Данная теория разделяет все факторы, влияющие на уровень удовлетворенности трудом и на мотивацию в целом, на две группы. К первой группе относятся так называемые «гигиенические» факторы. Они непосредственно связаны со средой, в которой выполняется работа. Эти факторы сами по себе не вызывают удовлетворенности трудом и не способны повысить мотивацию. Это не делает их менее важными. Отсутствие или недостаток данных факторов могут снизить мотивацию, приводя к неудовлетворенности. Иногда проявляется краткосрочный эффект повышения мотивации за счет «гигиенических» факторов, но не у всех и не всегда.
Приведу пример. Вам пообещали увеличить зарплату. Если у вас были проблемы с деньгами или вы уже давно ждали повышения, то до первого (максимум второго) получения повышенной зарплаты вы будете в приподнятом расположении духа. Возможно даже временно закроете глаза на некоторые другие факторы. А это положительно влияет на мотивацию. Но потом вы начинаете воспринимать новый уровень зарплаты как должное и само собой разумеющееся, как достаточный уровень «гигиенического» фактора. То же самое происходит с другими факторами из этой группы: большой монитор, удобное кресло, питание в офисе, тренажер в коридоре, курсы английского языка и т.д.
Ко второй группе факторов теория относит настоящие мотиваторы (мотивирующие к работе). Это личные достижения, признание заслуг, возможности карьерного роста, уровень ответственности, возможность творчества, самовыражения и прочие факторы, связанные больше с содержанием работы. Влияние этих факторов на мотивацию очень большое. И даже не смотря на то, что некоторые просто «работают работу», творческие и интересные задачи способны зажечь в них искру энтузиазма. Ответственность тоже играет большую роль. Чем больше ответственности, тем выше человек себя ценит и тем больше он пытается сделать, чтобы оправдать выбор компании. Простой пример из психологических приемов преподавателей. В группе учащихся часто назначают старостой того, у кого самое плохое поведение и кто оказывает на других плохое воздействие. Новый уровень ответственности способен очень сильно изменить поведение человека, мотивируя его не только следить за собственными поступками, но и за поступками других учащихся.
Какая же правильная стратегия мотивации сотрудников? Тут все просто. Нужно держать «гигиенические» факторы на достаточном уровне и уделять внимание настоящим мотиваторам из второй группы. Уровень зарплаты, рабочее место, офисное помещение и прочие факторы должны быть на достаточном уровне (без изысков и преувеличений), чтобы не вызывать дискомфорта. А основной упор стоит делать на развитии навыков сотрудника, его карьере, творческой и профессиональной самореализации. А это интересные проекты, определенный уровень свободы в принятии решений, реальные перспективы карьерного роста, формирование самоорганизующихся команд, конференции и встречи различных сообществ, участие во внутренней жизни компании… Продолжать этот список можно долго. Желаю вам «правильной» мотивации!
А нужен ли на самом деле Scrum Master?
7 Сентябрь
На размышления о необходимости роли Scrum Master я задумался после неожиданного обсуждения этой темы в комментариях к подкасту с моим участием. Приведу некоторые из тезисов, которые там фигурировали:
- Scrum Master — фиктивная профессия, программисты, не умеющие хорошо пррограммировать
- Кто угодно справится с этой задачей
- Scrum Master гордится своими сертификатами, а продуктивность лишь падает
- Scrum Master – катализатор для роста эффективности команды только в умах зомбированных Scrum-конференциями
Вот как-то так. Эти тезисы и рассмотрим один за другим.
Scrum Master – это отнюдь не профессия, а всего лишь роль. Роль, которую может выполнять человек, уже обладающий другими ролями. К примеру, это зачастую менеджер, ведущий разработчик, лидер команды. Любой, кто полностью понимает и осознает суть методологии Scrum, ее ограничения при использовании в данном конкретном проекте, а также готов следить за «правильностью» применения выбранных практик и подходов. Человек в этой роли должен выделять время на помощь команде в избавлении от препятствий, быть в роли ведущего на всех встречах, тщательно следить за потраченным временем и соблюдением договоренностей между всеми членами проекта. При этом он должен быть готов к изменениям в подходах, и поэтому не должен быть догматиком, слепо следующим прочитанным «истинам». Вот в принципе краткий список требований к этой роли. Кто должен ее брать на себя? Из моего личного опыта я считаю правильным отдать эту роль кому-то из команды разработки. Менеджеры слишком рискованные кандидаты на эту роль, потому что у них остается соблазн «управлять» и «указывать», а роль совершенно не такая. Она больше «наблюдательная» и «рекомендательная». Я встречал команды, где эта роль передавалась от итерации к итерации, чтобы каждый мог на себе почувствовать ее воздействие. Резюмируя, роль и специальность (профессия) – несколько несвязанные понятия. Поэтому не стоит их сравнивать.
«Кто угодно» – это достаточно размытое утверждение. Выше были перечислены требования к роли Scrum Master. Кто угодно, подходящий под эти требования, действительно способен справиться с ней. Кто угодно вообще – нет. Также как и с другими ролями: лидер команды, Product Owner, аналитик (это не всегда специальность), архитектор. У каждой из них есть свои требования. Мы все знаем, что случается, если роль берет на себя неподходящий человек. Провалы, срывы сроков, пустая трата времени и т.д. С ролью Scrum Master дела обстоят еще хуже. В современной разработке многие компании возлагают на Agile подходы очень много надежд. Провал в одном проекте может повлиять на глобальный переход к Agile подходам во всей компании. При таком риске очень важно тщательно подойти к выбору человека на роль Scrum Master.
Сертификация Scrum Master – это бич современности в IT. Мало того, что в название роли заложили слово Master, а это уже говорит о профессионализме, так дополнительно выдается сертификат после пары дней тренинга. И это говорит уже о том, что вы признанный профессионал Scrum методологии и готовы начинать работать в этой роли хоть завтра. Вернитесь и перечитайте требования к Scrum Master. Должно пройти немало времени, чтобы пропустить через себя все практики и набраться реального опыта. Только тогда можно принимать ответственные решения, которые принимает Scrum Master. И, пока к этим сертификатам относятся с уважением, провалы с применением Scrum не будут заканчиваться.
Scrum Master является катализатором роста эффективности команды в том случае, если он является лидером, мыслящим человеком и наглядным примером для членов команды. Это сочетание способно действительно повысить эффективность в разы. Постоянный анализ ситуации на проекте, видоизменение или настойка практик в соответствии с его особенностями, внедрение на собственном примере новых и полезных подходов дают отличные результаты. И тут как раз очень неплохо, чтобы Scrum Master был как можно ближе к команде, а не являлся обособленным ее членом.
В заключение, хочу затронуть тему вакансий Scrum Master на полный рабочий день. На первой стадии перехода к Scrum работа в этой роли действительно может занимать много времени. И очень важно не урезать время на нее. При правильной работе по внедрению Scrum времени должно тратиться все меньше и меньше. У всех по-разному: 10%, 20% или 50%. Зависит от размера и состава команды, взаимоотношений с заказчиком, сложности проекта и многих других факторов. Задача хорошего Scrum Master состоит в том, чтобы минимально воздействовать на процесс, лишь наблюдая и немного корректируя. Вот и получается, что после некоторого времени Scrum Master становится просто нечего делать большую часть времени. И ему надо либо переходить на другой проект, где возможно его роль не нужна, либо бездельничать. Поэтому я больше являюсь сторонником выбора Scrum Master непосредственно из членов команды.
Как быстро перейти в менеджеры
30 Июнь
Эта статья навеяна одним из докладов конференции Стратоконф-2, которую я «посетил» в прошлую субботу 25 июня. Посетил я взял в кавычки, потому что конференция проходила онлайн и можно было принять участия не покидая рабочего места (а суббота была рабочая в Украине). Один из докладов был на тему становления менеджера и как часть этого процесса рассматривался процесс перехода на позицию менеджера. Я бы хотел поделиться надежным и быстрым способом перехода на данную позицию с минимальными усилиями. Хочу сразу оговориться, что быть хорошим менеджером и перейти на позицию менеджера – это совершенно разные вещи. Непосредственно на позиции менеджера все будет зависеть от ваших навыков, способностей и желания работать над собой. Еще одно предупреждение – данный способ иногда предполагает некоторые временные уступки (по заработной плате или интересности проекта).
Итак, начнем! Вы разработчик, лидер команды, тестировщик или бизнес аналитик, который очень хочет стать менеджером. Причины могут быть разные, начиная от «великой карьеры» и заканчивая возможностью больше зарабатывать. Последнее в наших странах с большим числом аутсорсинговых компаний очень актуально, к сожалению. Но вы не знаете с чего начать свой «крестовый поход». Я приведу детальный пошаговый алгоритм:
-
Перед тем, как начинать масштабные действия, подумайте еще раз нужно ли вам это. Подумайте хорошенько. Ответьте себе четко и детально еще раз на вопросы: «Зачем мне это нужно?», «Чем я готов пожертвовать для достижения цели?», «Подхожу ли я на эту роль?», «Что делать, если я не подойду?». Если у вас нет уверенности в своем решении, то лучше не начинайте. Нет ничего смешнее, чем неуверенный в себе менеджер, особенно в начале карьеры. Уверенность вам понадобится для осуществления остальных пунктов плана.
-
Придите к руководству и четко изложите свое желание стать менеджером. Вы находитесь в очень выгодном положении. В связи с тотальной нехваткой хороших менеджеров, да и вообще хороших сотрудников, компании зачастую выгодно иметь «желающих» продвигаться по карьерной лестнице. Но это правило действует не везде и не всегда. Поэтому будьте готовы к долгим и упорным уговорам со стороны руководства остаться на занимаемой должности.Вот тут вам первый раз пригодится уверенность в своем решении. Объявите, что вы приняли окончательное решение и будете реализовывать его во что бы то ни стало, но вам бы очень хотелось при этом продолжить работать в компании. Желательно снабдить это заявление многочисленными комплиментами в адрес компании, руководства, сотрудников и проектов (конечно, если вы действительно хотели бы остаться).
Вам могут задать вопрос по поводу опыта и умений для работы менеджером. Вам стоит уверенно указать на желание расти и развиваться, которое вы будете реализовывать в ближайшее время. Теперь вы еще в более выгодной ситуации. Получается, что вы «белый и пушистый» и очень хотите вырасти, тем самым принося компании еще больше прибыли. В большей части случаев такой план действий срабатывает отлично и вам предлагают план по вашему переходу на должность менеджера. Продолжительность плана зависит от многих обстоятельств (ваша текущая позиция, наличие новых проектов, время на вашу подготовку, отпуска и т.д.), поэтому я не буду обсуждать эту тему. Еще раз напомню – тут очень важна уверенность в принятом решении и готовность уволиться в случае провала первой части плана.
-
Если первая часть плана не удалась, не расстраивайтесь. Это даже к лучшему. Теперь вы очень выгодный кандидат на рынке труда. Я постараюсь объяснить почему. Дело в том, что вами «движет» не финансовая мотивация, а желание профессионального роста. А это как бальзам на душу работодателю и HR. Во-первых, это дает им возможность поторговаться с вами по поводу зарплаты и условий перехода. Во-вторых вы абсолютно честны с ними, что легко проверить. Вы действительно уходите из компании, потому что она не дала вам возможности роста, к которому вы стремитесь. И, наконец, само стремление заниматься самообразованием и расти профессионально – это очень хорошая инвестиция для компании.Снова не стоит забывать про кризис на рынке труда практически во всех областях IT индустрии.
Вам нужно внимательно подойти к составлению резюме. Не нужно перечислять в нем все ваши заслуги на текущей и прошлых должностях. Вместо этого посмотрите на свой опыт под призмой будущей позиции менеджера. И красиво опишите свои преимущества. Например, технический опыт в разработке распределенных систем, организация и руководство командой из других разработчиков или помощь в постановке процесса тестирования в компании. Смело указывайте, что опыта работы менеджером у вас нет и вы это понимаете, поэтому готовы также идти на уступки. Этим вы забиваете последний гвоздь в корабль успеха. Но помните, что временно вы можете потерять в уровне зарплаты или других условиях. Не стоит расстраиваться. Все это легко окупится, если вы проявите себя талантливым менеджером и получите опыт работы на данной позиции.
-
Перед тем, как двигаться дальше, вам нужно немного «войти в тему». Для этого прочитайте пару книжек по современным подходам к управлению и ведению проектов. Думаю, что на сегодняшний день Agile методологии наиболее актуальны (Scrum, XP, Kanban и т.д.). Не выбирайте сложных и больших книг. Вам важно понять суть происходящего и вашу потенциальную роль в этом процессе. Пообщайтесь с другими менеджерами, узнайте как можно больше о данной должности от разных людей из разных компаний. Посетите конференцию или другие локальные мероприятия на тему управления проектами. И самое главное – слушайте и задавайте много вопросов. Все это пригодится вам в дальнейшем для осуществления второй части плана. Вы должны неплохо владеть предметом для прохождения собеседований.
-
Разместите свое резюме сразу в нескольких ресурсах и уведомите свою компанию об уходе. Не спешите с выбором компании. Пройдитесь по собеседованиям, присмотритесь к вакансиям. На всех собеседованиях смело и уверенно рассказывайте про полученные теоретические знания, ваше видение процесса разработки и вашу роль в нем. Отметьте, что у вас нет реального опыта, но вы очень хотите его получить. Вам будет легко, потому что вы полностью искренни. Ни в коем случае не врите. Это может плохо повлиять на результаты собеседования. Как один из своих плюсов отметьте еще раз желание и способность к самообразованию. Расскажите каких результатов вам удалось добиться за последнее время: вы вступили в тематические группы, посетили тренинги или конференции, прочитали книги, подписались на рассылки и т.д. С учетом возможности торга с вами, вы реально выгодный кандидат. Поэтому, через пару недель вы будете иметь несколько предложений.
-
Самый важный пункт. Если у вас по-прежнему ничего не получается, ни в коем случае не бросайте эту затею. Проведите ретроспективу, попытайтесь понять что вы сделали не так и что можно было бы сделать лучше. Компаний очень много и у вас будет еще не одна возможность. Честный анализ и постоянная работа над собой обязательно приведет вас к успеху.
В случае успеха перед вами открываются новые возможности и горизонты. И тут уже все будет зависеть от вас. Вы, возможно, так и не станете хорошим менеджером и пожалеете о своем решении. Может быть ваша карьера менеджера сложится удачно. В любом случае, вы никогда этого не узнаете, пока не попробуете и не сделаете шаг в сторону нового для вас мира. Удачного вам пути!
Новые встречи «Клуба анонимных разработчиков»
24 Июнь
Мы продолжаем развивать «Клуб анонимных разработчиков» и рады сообщить вам о новой встрече 5 июля в Киеве. На этот раз она будет посвящена использованию распределенных VCS в современной разработке. Это очень актуальная тема, потому что распределенные VCS (Mercurial, Git, Baazar) приобретают все большую популярность и начинают использоваться повсеместно. С их помощью многие процессы в разработке существенно упрощаются, а некоторые проблемы исчезают целиком. Но стоит ли переводить уже существующий проект на распределенную VCS? С чего начать подобную миграцию? Какие есть варианты использования? Для всех ли проектов данные системы будут одинаково полезны? Все эти и многие другие вопросы мы хотели бы обсудить на встрече.
Мы ищем желающих выступить с мини-докладами на указанную тему. Несколько кандидатов у нас уже есть, их имена объявим на следующей неделе. Мы приглашаем всех, кому интересна эта тематика, поучаствовать в дискуссии и высказать свою точку зрения. Возможно вы являетесь ярым сторонником классических VCS. Ваше мнение и опыт также будут полезны участникам. Приходите, будет интересно!
Встреча запланирована на вторник 5 июля. Как и прошлый раз она состоится в Киевском офисе компании DataArt. Официальное начало в 19:00, завершение в 23:00. Надеемся, что этого времени хватит всем, чтобы пообщаться вдоволь. Адрес места проведения: Бехтеревский переулок, 14E. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Уютная атмосфера и все необходимое для продуктивного общения будет обеспечено. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 30 участниками.
Мы готовим встречи и в других городах Украины, к примеру в Харькове. Следите за анонсами на нашем сайте или группе в LinkedIn. Скоро мы начнем обширную программу по обеспечению льгот для членов клуба. Они смогут получать скидки на различные мероприятия из мира разработки, тренинги и конференции. Это будет дополнительным стимулом для вступления в клуб. Если у вас есть еще идеи по поводу деятельности клуба, то пишите в комментарии или на почту. Присоединяйтесь к нам!
Стоит ли отказываться от оценок?
11 Апрель
Вчера появилась статья с перечислением причин бесполезности оценок, продолжением которой стал перевод на английский язык. Автор видит в оценках только waste и предлагает поскорее отказаться от этой вредной привычки. В качестве основных аргументов приводятся 5 причин. В одно предложение высказать свое мнение по этому поводу не получилось, да и нету аккаунта с возможностью писать комментарии, поэтому решил написать ответную статью.
Первой причиной автор называет потерю времени на процесс оценивания. Для меня подобный подход очень забавен: увидел длительную активность – отмени ее. Под этой эгидой можно отменить все митинги – соберемся когда припечет очень сильно, а можно и вообще не собираться. Следом за митингами в мусорку отправляется демо. Надо будет заказчику – сам зайдет и посмотрит. Так же можно поступить с любыми другими активностями, отнимающими хоть какое-то время. И тогда можно будет только и делать, что писать код. Никому не нужный код. Оптимизация любого процесса включает в себя избавление от waste, но не отменой важных шагов процесса, а их оптимизацией. Нужно сделать так, чтобы на каждом шаге тратилось минимальное количество времени для достижения целей. Отказываться от шага нужно только в том случае, если он не приносит никакой пользы.
Вторая причина вообще комична. Мы не делаем оценок, чтобы потом никто не спросил почему так долго делается задача. А даже если и спросил, то мы вроде как ничего и не обещали. С точки зрения разработчика, оно выглядит заманчиво. Ведь заказчик не очень силен технически. Можно спокойно работать в половину силы, а потом в качестве аргументации привести пару сложных технических терминов и дело сделано. Я не позавидую заказчику в такой ситуации, да и сомневаюсь, что такой подход кого-нибудь устроит. Он работает замечательно в только в том случае, когда мы имеем сознательную, организованную и хорошо мотивированную команду. Особенно, если команда сама заинтересована в успехе проекта. Но, в разрезе аутсорса, это практически невиданная ситуация.
Третья причина взывает к излишней оптимистичности оценок, которые свойственно давать программистам. Совершенно согласен, что дело с оптимистичностью оценок обстоит именно так. Но очень легко ситуация меняется после анализа нескольких проваленных итераций. Некоторые команды уже на второй итерации очень сильно понижают свой оптимизм. Постоянная практика оценивания только способствует развитию реалистичного взгляда на сложность разработки, что является очень полезным навыком.
Четвертая причина говорит о давлении на команду. Да, сильное давление никогда не приносит пользы и часто замедляет работу. Но вот легкое давление позволяет держать фокус на задаче и быть в тонусе. Непонятны примеры с принятием первых попавшихся архитектурных решений и угрозой качеству. Когда оценки делает команда, которая и будет разрабатывать задачу, то она должна давать такую оценку, чтобы комфортно сделать качественное решение. Никто не должен делать оценку за команду. Даже в случае проваленной оценки стоит поднять вопрос о выделении дополнительного времени или урезании функциональности. Делать некачественно – не единственный выход. К сожалению, вообще без дедлайна мы все становимся заложниками закона Паркинсона о тенденции работы занимать все отведенное под нее время. Часто незаметно для нас, задача занимает гораздо больше времени, если это самое время не контролировать. А это может негативно отозваться на ваших отношениях с заказчиком и коллегами.
Последняя причина связана с фокусом на важных вещах. Тут все вообще непонятно. Как связаны оценки с приоритетами задач? В Scrum только Product Owner управляет приоритетами и его выбор может зависеть или не зависеть от ваших оценок. Но, добровольно брать задачи «попроще» – это принцип, который противоречит разумной логике определения функционала проекта на итерацию или релиз. Большая оценка говорит заказчику о том, что, возможно, стоит повременить с данной функциональностью в пользу другой чуть менее важной, но гораздо более простой. Это всего лишь дополнительная информация для принятия правильного решения.
Так стоит ли отказываться от оценок? На мой взгляд, только при определенных обстоятельствах. К примеру, если планирование вашего продукта не предполагает вариаций на тему объема функциональности. То есть, либо продукт готов целиком, либо он не готов вовсе. В таком случае, если вам повезло с замотивированной командой профессионалов, то оценки почти не представляют ценности. Вы и так знаете, что команда сделает все правильно: разобьет большие задачи на части, будет контролировать время разработки, сделает выводы из собственных ошибок, произведет нужный функционал вместо интересной архитектурной поделки и так далее. При этом можно работать как итеративно с использованием Scrum, так и с потоковой моделью Kanban. Только для определения объема работ на итерацию нужно использовать другие методики, отличные от Velocity. Приведенный пример скорее является исключением из правил, особенно в контексте рынка аутсорсинга.
Практика оценивания и правильного использования оценок для улучшения процесса разработки является очень интересной темой. Я планирую рассказать о ней подробнее в своем докладе «Методы оценок в Agile проектах» на конференции AgileBaseCamp Киев 16 апреля. Приходите, будет интересно!
Появилось видео нашего доклада с AgileDays’11
31 Март
Мы рады сообщить, что появилось видео с нашего доклада «Что означает ‘Готово!’ — применение практики Definition of Done» на конференции AgileDays’11. О том, как проходила сама конференция вы можете узнать из нашего отчета в двух частях. Видео остальных докладов с конференции постепенно появляется и может быть найдено на странице технического партнера, отвечающего за съемку. Это отличная возможность для тех, кто не попал на конференцию или пропустил интересные для себя доклады, наверстать упущенное.
Новый тренинг «TDD в PHP» пройдет 18-19 марта в Киеве
11 Февраль
Благодаря совместным усилиям Алименкова Николая и нашего нового тренера Ивана Мосева, мы рады представить вашему вниманию новый тренинг «TDD в PHP».
Test Driven Development (TDD) без сомнения является одной из наиболее полезных, но в то же время трудных для внедрения, инженерных практик. TDD предлагает писать тесты до того как реальный код появится в приложении, благодаря чему вы получаете лучший дизайн, больше фокусируетесь на функционале, имеете возможность проверить состояние своей работы и понять когда вы закончили. Но написание тестов перед кодом требует от разработчика изменения мышления и наличия большого опыта в тестировании.
Данный тренинг предназначен для PHP команд или индивидуальных PHP разработчиков. Он поможет вам понять преимущества внедрения TDD на вашем проекте, сложности и пути их преодоления. Тренинг посвящён использованию модульного тестирования для улучшения процесса проектирования и разработки приложений на PHP. Будут расcмотрены инструменты, которые применяются для тестирования в PHP, и весь технологический процесс разработки, непрерывной интеграции и поставки web-приложения на PHP на примере практического задания, которое будет разрабатываться в процессе тренинга. Также будут рассмотрены полезные практики и инструменты для облегчения работы по TDD.
Первый тренинг пройдет в Новосибирске 19 февраля, а следующий – в Киеве 18-19 марта. Регистрация уже открыта и продлится до 14 марта. Продолжительность тренинга 2 дня, стоимость участия – 1600 гривен (обеды включены). Торопитесь, максимальный размер группы – 10 участников!
Отчет о первой в Украине Agile PechaKucha
28 Январь
Вчера на территории компании Ciklum прошла первая в Украине встреча Agile PechaKucha. Это была встреча в неформальной обстановке с пивом, пиццей и насыщенным общением. Собралось немало людей, заинтересовавшихся данным форматом встреч. Некоторое время назад я описывал как проходят такого рода мероприятия. Мои впечатления сугубо положительные. Формат понравился – все очень быстро и динамично, без скучных долгих докладов. Времени хватает и на то, чтобы послушать докладчика и задать все интересующие вопросы. Докладчики тоже порадовали своей подготовкой, презентации получились очень живые. Большое спасибо организаторам за то, что пригласили поучаствовать и выступить с докладом. Я подготовил доклад «Agile. The way from chaos to flow» на тему эволюции Agile подходов и важности всех шагов на пути каждой команды.
Алексей Солнцев выступил с докладом «Agile: вид из окна тренажёрного зала», в котором провел параллель между Agile подходами и занятиями в тренажерном зале. В докладе прозвучало множество конкретных примеров и аналогий из жизни, интересные советы и практики. Данная аналогия заставила взглянуть под другим углом на процесс разработки и управления командой.
Хотелось бы пожелать организаторам успехов в этом начинании и еще много интересных встреч в формате PechaKucha!
Найм сотрудников. Часть 1 – Профессионализм.
24 Декабрь
Хочу продолжить давнюю тему о найме сотрудников, начатую некоторое время назад Тимофеем Евграшиным. Мне по долгу службы приходится очень часто проводить собеседования. Больше всего собеседую Java программистов и технических лидеров разного уровня для проектов компании. В этой серии статей я хочу поделиться своими наблюдениями, мыслями, идеями и приемами проведения собеседования.
Первая часть будет посвящена такому интересному явлению как «профессионализм». Это вроде бы очень простое и часто употребляемое понятие, но каждый вкладывает в него совершенно разный смысл. Большая часть людей, проходящих собеседование, считают себя профессионалами. Почему же тогда заявленный уровень знаний и опыта сильно расходится с действительностью? Для чего в резюме включено столько различных аббревиатур, представляющих технологии, инструменты и языки программирования? Как может Java разработчик с опытом работы более 7 лет не разбираться в JMS? Я задавал себе эти вопросы не раз и, мне кажется, я знаю ответ.
Многие из программистов привыкли думать, что компания-работодатель отвечает за их карьеру, опыт, технологический рост и накопленные знания. Я не знаю откуда взялось такое предубеждение. Может быть из университета, где дела обстояли именно так, может быть от специфики индустрии или по неизвестным мне причинам. Эта мысль выстраивает весь остальной путь развития такого программиста. Он не изучает технологии, которые не применяются в проектах, он не ходит на тренинги и конференции, если их не оплачивает компания, он не следит за тенденциями в индустрии и новыми технологиями. Но разве в этом заключается профессионализм? Настоящий профессионал сам отвечает за свое образование и развитие. Он инвестирует свое время в развитие, изучение технологий, общение с коллегами, чтение технической литературы и многое другое. Отношения с работодателем рассматриваются только как контракт, в результате которого вы получаете материальную прибыль за выполнение определенной работы.
В этом случае цена контракта напрямую зависит от ваших профессиональных навыков, от того, насколько хорошо вы делаете свою работу. Система обретает логичность – вы вкладываете в себя, компания платит вам согласно успешности вложений. Вам выгодно продолжать вкладывать, потому что тогда вы можете повысить свою стоимость. Что же происходит на рынке труда в IT? За счет кризиса профессиональных кадров многие компании пилят сук, на котором сидят. Они сначала вкладывают средства в развитие сотрудника, а потом сами же за это ему платят в виде повышения заработной платы. Доходит до абсурда, когда сотрудник приходит на тренинг, на который никогда бы не пошел в случае самостоятельной оплаты (хотя бы минимальной). Я не знаю ни одной индустрии с похожей ситуацией.
Вторая черта, присущая профессионалам – это ответственность за свою работу. Профессионал не выпустит код, который он ни разу не запускал, надеясь, что отряд бравых тестировщиков найдет все допущенные ошибки. Он неоднократно проверит свой код и приложит максимум усилий к тому, чтобы не было найдено ни одного дефекта. Возвращаясь к предыдущей мысли по поводу контракта, нужно отметить простой принцип – чем качественнее и эффективнее вы работаете, тем на большую сумму контракта вы можете претендовать. Но за качество должен отвечать сам сотрудник, прилагая максимум усилий, чтобы его повысить. Я рад, что в последние пару лет наблюдается заметный рост в использовании практики модульного тестирования кода. Теперь почти каждый собеседуемый если и не пишет модульных тестов, то осознает их важность и полезность. А это шаг в правильном направлении.
Ответсвенность важна не только на уровне написания кода. Мы все работаем в команде, состоящей из разных людей. Профессионал должен это четко понимать и брать ответственность за результаты командной работы. Без командной работы результаты одного человека теряются на фоне общего провала команды. Фразы «зато моя часть кода работает» и «я то пишу код без багов» никак не улучшают общую тенденцию, возможно даже наоборот. Профессионал стремится приложить максимум усилий для того, чтобы улучшался командный результат. Это касается качества кода, оценок и планов, процессов и практик. Профессионал не гонится сугубо за собственной эффективностью, а успехи в улучшении командной работы дают ему дополнительные баллы к условиям контракта.
Многие программисты не практикуют написание кода. То есть, они конечно пишут код на работе на своем проекте, но не более чем. Работая на одном проекте в течении года, многие программисты изменят свой стиль и практики, следуя проектным стандартам. Но они не всегда есть и далеко не всегда достаточно хороши. Профессионал же пытается привнести в проект полезные практики, пишет код того уровня, который удовлетворяет его внутренним стандартам. Он не увязает в «болоте» существующего кода, а старается превратить его в «красивое озеро». Для этого нужна практика, лучший способ получить которую – это писать код. Писать код в паре с другим программистом (не обязательно из вашей команды), участвовать в разработке разных модулей системы, проводить ревью чужого кода, свободное время практиковаться в рефакторинге существующего кода. Существует еще немало способов. Те же самые правила распространяются на архитектуру и дизайн. Важное качество профессионала в данном случае – это инициативность.
Все мы хотели бы работать с профессионалами, потому что они грамотно делают свою работу и у них есть чему поучиться. К сожалению, встречаются они не так часто. Чтобы исправить ситуацию стоит самим сделать шаг в сторону профессионализма и начать двигаться в этом направлении. Читайте больше технической литературы, изучайте основные технологии из вашего направления работы, посещайте конференции и смотрите выступления онлайн, подпишитесь на блоги и новостные порталы, чтобы быть в курсе событий. А главное, практикуйте много и постоянно.
В следующей части я расскажу как за время собеседования сложить представление об уровне профессионализма кандидата. Оставайтесь с нами!







