WhaleRider2010 – впечатления от докладов (день 2)
Из ленты: Control freak
Признаюсь, выступления второго дня я воспринимала сквозь лёгкий туман – думала о предстоящем выступлении. Но кое-что всё же услышать и осознать смогла.
Утро, говорят, хорошо начинать с зарядки. Я вместо этого отправилась на доклад «Темная сторона луны: когда от обучения может стать хуже» тренера Вячеслава Панкратова. Вступление началось с подробнейшего рассказа о своём профессиональном пути. Даты, должности, фирмы. Вероятно, таким образом Вячеслав решил показать, что его желание учить, консультировать, советовать произросло не из невозможности найти применение собственным способностям, а из обширного опыта.
Прозвучавшая цель тренингов – вырабатывать навыки, а не только давать знания, – многократно подтверждается моим собственным опытом. И правда, обидно вспоминать, сколько полученных знаний не перешли ещё в умения, не доведены до автоматизма и потому не применяются в нужных ситуациях. Вячеслав довольно подробно рассказал об особенностях обучения взрослых. Как донести мысль, минуя защитные механизмы человека, которому объясняют, что он что-то делает неправильно. Как преодолеть сопротивление работающего опыта. Как добиться перехода от неосознанного незнания к осознанному. Как подвести людей к нужному решению так, чтобы они считали его своим. Как, наконец, подкреплять похвалами свежеприобретённый опыт и первый эксперимент по его использованию. Закончил Вячеслав призывом выбирать не столько программу обучения, сколько тренера. И я знаю, кого выбрала бы после этого выступления.
Байрам Аннаков начал рассказ об «Управлении распределенной командой разработчиков» с того, что мне бы хотелось сделать самой, – отказался от использования микрофона, чтобы иметь возможность свободно жестикулировать обеими руками. Завидую смелости.
Вопреки заявленной теме, рассказ был посвящён принципам, применимым как для распределённой, так и обычной команды. Перечислю только некоторые из них.
Работать лучше не с кодерами, а с разработчиками, умеющими задавать вопросы «зачем» и «почему». С людьми, умеющими подниматься над зоной непосредственной ответственности и понимать более общие постановки и требования. Идея, что для развития эмпатии надо предлагать разработчику самому пользоваться разрабатываемым продуктом и тем самым почувствовать себя в роли пользователя, революционной мне не показалась; у меня в команде все нашим сервисом пользуются, и это даже не обсуждается никогда. А вот принцип получения обратной связи от системы для немедленного влияния на пользователя показался необычным. В качестве примера предлагалась форма на сайте службы заказа такси, которая становится неактивной, когда все машины расписаны на ближайшие несколько часов.
В качестве одного из инструментов Байрам предложил использовать прозрачность работы, и не столько для заказчика, сколько для самой команды, чтобы разработчики могли оценивать вклад каждого, чтобы люди начали подталкивать и тянуть друг друга. Для организации такой прозрачности, помимо постоянных совещаний и встреч, можно использовать прототипы (с максимально реальными данными, с эмуляцией задержек в получении данных) в качестве приятного промежуточного результата, вдохновляющего на завершение длительного проекта. Полезно показывать разработчику полный статус проекта, чтобы он видел, например, что хотя его часть работы давно завершена, проект в целом ещё не сдан заказчику и потому не закрыт. Например, это поможет объяснить, почему премия будет только через несколько месяцев.
Предлагалось также внедрить армейский принцип «получил приказ – повтори его». Для чего? Чтобы убедиться, что разработчик понял задачу полностью и верно. Необходимость вести записи во время любых обсуждений обосновывалась тем, что только так человек успеет подумать (и задуматься) над обсуждаемым вопросом.
В какой-то момент Байрам стал утверждать, что нужно говорить с разработчиками (и учить этому их), предлагая решения вместо жалоб. С точки зрения пользы дела это, безусловно, так. Но иногда очень хочется именно выговориться, облегчить душу, а придумывать способы и подходы захочется потом, когда уйдёт эмоциональная составляющая проблемы.
Упоминался ещё один важный лично для меня как разработчика, а не руководителя, принцип: хвалить и ругать нужно сразу. А хвалить желательно ещё и публично. Все это знают, но не все применяют. И если Байрам действует именно так – как же повезло его разработчикам.
И так далее, и так далее. С видео-вставками и призами наиболее активным слушателям. Отличный доклад! Единственное, что может несколько снизить градус моего отзыва, это предположение, что большая часть сказанного относится к управлению каким-то немного виртуальным и не самым сильным разработчиком. Не могу представить, чтобы серьёзного работника так уж мотивировала выданная фирменная футболка и совместная игра в регби.
Формулировка темы доклада Германа Клименко «Секреты оптимизации и найма программистов» показалась мне очень-очень странной. Оптимизация – чего? С одной стороны – чего? Грибааааа. Оказалось – речь о поисковой оптимизации сайтов. А при чём здесь программисты, спросите вы вслед за мной. Оказывается, с разработчиками, как с заказчиками SEO, нужно быть очень терпеливым.
А дальше последовал поток утверждений, после каждого мне хотелось то ли демонстративно выйти, то ли горько рассмеяться, то ли попросить микрофон и задать единственный вопрос: «вы это всё серьёзно?». Поделюсь особенно яркими примерами:
Программистов надо заставлять взаимодействовать друг с другом. Сами, по доброй воле, они не будут делать этого никогда.
Не нужно требовать документирование кода, бесполезно. Всё равно с передачей разработки другой команде весь код будет переписан заново. Ну да, если вы можете себе это позволить… (Я, как раз, очень люблю порассуждать об осмысленности документирования.)
Программисты всегда опаздывают и это нормально. С нажимом так. Если разработчик приходит к 9 утра и уходит в 18, это не настоящий программист, это какой-то другой подвид, несуществующий. (Ну да, ну да…)
Что хвалить не обязательно, и достаточно, как в армии, не наказывать за допущенные ошибки.
Наконец, что программисты – это совершенно неконтролируемый тип людей. Ну что тут скажешь? Наверное, вы просто не умеет их готовить.
Следующий доклад, Дмитрия Башакина «Жизненный цикл команды: академический термин или практический инструмент менеджера?», показался мне по сравнению с предыдущим выступлением образцом корректности и вдумчивого подхода к произносимому. Хотя мне показалось, что тема, процесс командообразования, была подана немного слишком академично, возможно, я просто не являюсь целевой аудиторией подобных рассказов, так как намного легче воспринимаю отсылки к практике и опыту, чем к теории.
О моём собственном выступлении – «Скорость разработки» – корректнее писать другим. Моим читателям могу предложить пока только пробежать глазами по презентации и дождаться, пока я превращу её в статью, а сделаю я это обязательно, так как тема меня сейчас очень сильно волнует.
В целом, впечатления от конференции остались самые приятные, за что большое спасибо организаторам.