1. Программирование - твоя главная страсть. И да не будет у тебя страсти главней.

2. Не сотвори себе кумира из конкретной технологии. Ибо программирование требует постоянного развития, а технологии-кумиры останавливают развитие.

3. Не возноси хвальбу программированию в неподходящей компании. Ты сам себя накажешь, ибо будешь не понят, и люди отвернутся от тебя.

4. Работай много и хорошо, но не забывай и про отдых. Ибо нет ничего страшнее, чем код усталого, засыпающего программиста.

5. Уважай учителей и учеников своих. Постоянно учись и учи окружающих, чтобы было тебе всё легче и легче делать всё более и более сложные вещи.

6. Не убий в себе ребенка. Не забывай эмоции от первого запуска первой написанной тобой программы и воспринимай каждую следующую, как ту - первую.

7. Не изменяй программированию. Ибо программист может стать кем угодно, но этот кто угодно обратно программистом уже не станет.

8. Не кради код ближнего своего.

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

10. Не завидуй ближнему твоему, если он умеет лучше программировать. Ибо программирование - это божественный дар, но его можно развить. Так что не завидуй, а развивай.



Понравилась статья? Подпишись на RSS!

Когда я начал звать народ на собеседования, то быстро понял, что в простом разговоре невозможно понять уровень программиста. Есть люди, у которых на сложные вопросы есть ответы, которые знают неплохо теорию, но на практике делают все медленно, а то и вообще не могут ничего сделать.
К тому же я был увлечен Джоэлем Сполски и сильное влияние оказала его фраза “Лучше не нанять 10 хороших программистов, чем нанять 1 плохого”. В итоге весь процесс собеседований был направлен именно на то, чтобы не взять плохих программистов.
Сначала я критически читал резюме. Тут я применял небольшой трюк: если человек был без опыта работы или студент, то я часто звал его на собеседование, так как слишком часты бриллианты среди студентов, к тому же переучивать его не надо и банально - платить ему можно меньше. Если же человек был с опытом работы, то я просил его расписать подробнее чем он занимался и чего достиг за предыдущие годы. Если ничего внятного человек написать не может - я его не приглашал на собеседование, ибо, если программист не достиг ничего за несколько лет, то почему он должен измениться?
В конце я также применял несколько раз телефонные интервью и это помогло отсеять несколько кандидатов. Но я себя неуютно чувствовал, разговаривая по телефону, поэтому не практиковал это очень часто.


С теми, кто попал на личное интервью, я сначала беседовал на личные темы, про старую работу, про прочитанные профессиональные книги, про лучший проект или код, который они написали и т.п. - это дает отличное представление о личности человека. Эта вступительная часть собеседования была направлена на то, чтобы человека раскрепостить. Это был не допрос - это было общение. Я водил претендента по офису, показывал наши рекламные ролики и игры, показывал, как мы работаем и чем занимаемся. Узнавал, что человеку интересно, а что нет. Мы никогда не сидели, разделенные столом, а все собеседования проходили в неформальной обстановке - на стульях в большой комнате у доски.
Потом я давал претенденту компьютер с открытым блокнотом и просил написать несколько простейших программ, типа “напишите функцию конвертирования int в строку” и “есть 100000 объектов в игре. для объекта X напишите функцию поиска 10 ближайших объектов в 3D мире. предложите будущие методы оптимизации этой функции.”. Мне не нужна была работающая версия всех функций и правильность синтаксиса. Мне нужно было видеть, как человек думает и как быстро может соображать.
Удивительно, но чуть ли не 90% претендентов проваливали этот тест совершенно. И их код был настолько неработоспособен и страшен, что было очевидно - мы не сработаемся. На этом их интервью заканчивалось.
Остальные делали что-то (а кто-то делал всё - и это были лучшие программисты в итоге) и получали задание на дом.
Да, после всего этого я давал еще и серьезное задание на дом, на которое разрешалось потратить вплоть до недели (чтобы проверить, я сам выполнил все эти задания. У меня ушло на каждое от 4 до 12 часов). Задания были типа “Написать игру “змейка”". Или “сделать физическую симуляцию колодца, в который кидают шары в 2d или 3d”.
Если программист прошел такое интервью и сделал домашнее задание, то он безусловно умеет программировать и учиться. Такие брались на испытательный срок.
На испытательном сроке они уже проверялись на реальных проектах и тут уже даже самый сильный программист может не выдержать пресса геймдева, что и случалось пару раз.
Еще интересное наблюдение - обычно очень сложно отказать человеку по результатам домашнего тестового задания, если он его выполнил, но не очень хорошо. Например, код некрасивый или неоптимально сделано, или глючит и падает. Кажется, что сделал ведь человек - надо брать. Но в итоге каждый раз оказывалось, что и в работе человек такой же, как и в тестовом задании. Я через себя тогда так и не смог перешагнуть и не помню, чтобы отказывал кому-то, кто выполнил тестовое задание, даже если оно мне не нравилось.
Сейчас бы я был жестче и простого плохого выполнения тестового задания было бы уже недостаточно.


Вот такой вот подход у меня был.
Конечно, кому-то он может показаться слишком жестким. Далеко не каждый программист может за час прямо на собеседовании написать требуемый код или потратить дома несколько часов\дней на написание тестового задания. Но в геймдеве нужны были именно такие, кто может и первое и второе. И я считаю, что именно такой метод интервьюирования и принцип “Лучше не нанять 10 хороших программистов, чем нанять 1 плохого” - позволили нам в свое время создать отличную команду, которая была готова к подвигам и совершала их.
А еще было очень приятно потом слышать от тех, кто проходил моё интервью, что они меня помнят и отзываются об интервью очень хорошо, даже если не прошли его. Оставить хорошее впечатление и не обидеть человека - это очень важно для интервьюера.


Похожие записи:
Православный Геймдев во всей его красе
Книги + программисты = деньги
Shu-ha-ri для программистов
25 самых опасных программистских ошибок

Понравилась статья? Подпишись на RSS!

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

Понравилась статья? Подпишись на RSS!

В японских боевых искусствах есть концепция трехэтапного обучения мастерству - Shu-ha-ri.
1. Shu (守:しゅ - “защита”, “подчинение”) — изучение традиционной мудрости — изучение основ, техник, движений.
2. Ha (破:は - “отделение”, “отклонение”) — отступление от традиции — поиск исключений в традиционной мудрости, размышление о правильности традиций, поиск новых путей и техник.
3. Ri (離:り - “покидание”, “отделение”) — превосходство над традицией — нет больше никаких техник или традиционных движений, все движения естественны и рождаются самостоятельно, а не из традиционной мудрости.


Любое обучение начинается с этапа Shu, когда ученик должен преданно следовать всем инструкциям своего учителя. На этом этапе нельзя спрашивать “почему”, нельзя ставить под сомнение правильность движения или слов учителя - только полное подчинение и следование инструкциям. На этом уровне ученик еще не готов к вопросам, а точнее - он не готов задавать правильные вопросы и не готов воспринять ответы на них. Только учитель может решить, что ученик готов перейти на следующий этап - этап Ha.


На этапе Ha ученик начинает изучать границы своей техники и постоянно должен спрашивать “Почему?”. Вопросы позволяют ученику лучше адаптировать под себя фундаментальные знания, которые он получил на этапе Shu. Ученик может даже находить новые техники усиляющие его потенциал.


И вот в определенный момент количество опять переходит в качество и ученик переходит на уровень Ri. На этом уровне больше нет никаких правил, точнее ученик сам создает правила. Ученику больше не надо спрашивать “почему” - он это уже знает или чувствует. Ученик готов к самостоятельному изучению движений, созданию новых движений, и он видит взаимосвязь между ними.

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


А при чем тут IT и программисты, спросите вы?



В книге Agile Software Development Alistair Cockburn применил те же самые 3 уровня развития, 3 уровня зрелости к применению командой методологий разработки ПО.
Что происходит, когда команда (или фирма) решает, что теперь она разрабатывает софт, используя SCRUM (или XP или что угодно)?
Сначала команда находится на уровне Shu и следует предписанным правилам - правилам из книг или полученным от консультанта. И книги и консультанты утверждают, что шаг влево-шаг вправо и методология не будет работать, поэтому команда не делает шагов влево или вправо.
Но в какой-то момент кто-то начинает спрашивать “Почему?” и команда переходит на уровень Ha. Это не всегда случается, например, если руководство давит все попытки что-то изменить (ага - это забавно, когда методология зовется “гибкой”, а изменять в ней ничего нельзя). На уровне Ha команда начинает менять методологию под себя.
Например, если это SCRUM, то команда может решить, что ей не нужны 5% workshops, или что она не хочет запрещать Product Owner-у добавлять новые задачи внутри итерации, или даже что ежедневные Scrum standup - это waste и их надо делать раз в 2-3 дня.
На уровне Ha команда избавляется от ненужного, что мешало ей в работе, а также может добавить в процесс что-то, что будет помогать. Как результат - рост производительности и самоудовлетворенности команды.
Команда продолжает изучать границы применимости методологии и вот в какой-то момент оказывается, что она уже на уровне Ri.
Она уже не ограничена никакими рамками конкретной методологии.
Она может выбирать самое подходящее из разных методологий, пробовать это и решать - подходит или нет.
Она может даже ненадолго полностью отказаться от одной методологии и переключиться на другую только затем, “чтобы попробовать”.
Такая команда работает еще эффективнее и это и есть та самая “команда мечты”, про которую писали ДеМарко и Листер в Peopleware. Такой команде просто не надо мешать, и тогда она сделает все, что от нее требуется.


Интересно, как проявляются проблемы с общением между людьми, находящимися на разных уровнях Shu-ha-ri.
Люди на уровне Shu не понимают (и не должны понимать) советов людей с уровней Ha или Ri. Для них эти советы слишком неконкретны и абстрактны, так как они призывают выйти за пределы инструкций, но Shu-человек еще не готов выходить за пределы - он просто хочет следовать конкретным инструкциям! А уж от советов Ri-людей Shu-человека просто коробит - Как это “Daily standup - это неважно, отмени их?”. Это же важнейшая часть SCRUM, придурок!.
Примерно такое же недопонимание царит и между уровнями Ha и Ri потому что на уровне “Ha” люди готовы исследовать границы методологии, но не готовы выходить за границы.


Те же самые 3 уровня развития можно применить ко многим вещам.
Например, к умению программировать.
Вначале программист находится на уровне Shu - он изучает язык или языки программирования, изучает алгоритмы, улучшает свои навыки написания программ, изучает предметную область и т.д.
Shu-программист может быть вполне успешным и Shu-программистов большинство в нашем мире.
Такой программист может отлично делать свою работу, если задание поставлено четко, но с трудом может ставить себе задачу сам. Он следует правилам разработки, принятым в его компании или отрасли и не спрашивает постоянно “почему?”, не пытается постоянно изменить что-то. Он “следует”, “течет по течению” и эти фразы лучше всего описывают таких программистов.
Уверен, что вы знаете немало Shu-программистов, потому что, подчеркну, их большинство. А может вы и сам - Shu-программист? Тогда читайте дальше и, возможно, вы сможете постичь третью ступень.
Ведь есть и Ha-программисты. Обычно они быстро выбиваются в лидеры или на руководящие должности, потому что они активны, задают вопросы, пробуют постоянно свои знания на прочность и расширяют их.
Ha-программисты готовы изучать новые языки программирования, переходить в новую отрасль для изучения новых знаний. Они готовы ставить под сомнение каждую задачу, которую они получают и каждую книгу или статью, которую они читают. Именно это постоянное сомнение и стремление к познанию порождает в их мозгу постоянную работу и размышления.
И со временем такой программист может достигнуть просветления и перейти на уровень Ri.
Ri-программист уже не думает о задаче, как об обособленной проблеме, но думает о ней, как о чем-то, что интегрировано в огромную систему, состоящую из других компоненов. Каждый класс или переменная - это не просто класс или переменная - это просто точка в огромном многомерном графе проекта.
Ri-программист не думает о том, как написать класс - он думает о том, как НЕ написать класс.
Для Ri-программиста нет задач, которые он не смог бы запрограммировать и главное для него в задаче - это не сложность, а важность.
Когда Ri-программист пишет код, то он не думает о языке программирования или операторах цикла - он видит многомерный граф проекта и расширяет его, а код рождается сам по себе.
Ri-программист оптимизирует граф проекта, а не конкретные функции, поэтому одно его правильное решение может сократить код проекта вдвое и одновременно улучшить качество или производительность.
Про Ri-программистов можно писать и дальше, но проблема, как я уже написал, в том, что невозможно научить быть Ri-программистом, невозможно даже описать что это такое - только другой Ri-программист сможет понять это. Так что, если вы видите смысл в строках про Ri-программиста, то welcome to the club.


А вы на каком уровне сейчас находитесь?
И, главное, что вы делаете и достаточно ли стараетесь для перехода на другой уровень?




Похожие записи:
Общение несовершенно - умей управлять несовершенностью.
Канбан в IT (Kanban Development).
Software Engineering is Dead?!


Понравилась статья? Подпишись на RSS!

1. Пользователь твоей программы - это не ты. Разработчики часто, очень часто забывают про это. Они пишут программы, ориентируясь на себя и свой уровень знания, а не на уровень знаний клиентов (пользователей). Отсюда проблемы с кривыми интерфейсами, сложными программами или отсутствием юзабилити  у продуктов. Ведь разработчик думает как? Для него следующее - это очень простая и правильная инструкция: “Чтобы сохранить документ - найдите папку, куда установлена программа, запустите файл savedoc.exe с параметром командной строки -s и именем файла для сохранения. Вы можете использовать дополнительные параметры: -m ….. “. Это простая инструкция? Возможно, да,.. для кого-то. Тогда как юзеру надо не инструкцию, а пункт SAVE в меню и всё. Никаких путей и командных строк. Такие “недоразумения” в дизайне случаются всегда, если техническим людям разрешено решать, что для пользователя просто и правильно, а что нет. И дело совсем не в том, что “пользователи все тупые”, а в том, что вы не должны требовать наличие у пользователя того же уровня знаний, какой есть у вас.
2. Нужно делать простые вещи простыми, а не давать возможность делать сложные вещи. Любовь к созданию сложных вещей - это очень широко распространенная особенность программистов и других технических специалистов. Программисты любят сложности. Они не любят делать простые вещи - они любят делать сложные вещи, которыми можно было бы гордиться. А между тем пользователям не нужны сложности - им нужна возможность очень просто делать простые вещи. Например, вспомните главную страницу гугла - это запатентованный идеал простоты. Невозможно сделать поиск проще. И пользователи это любят. Возьмите любой другой поисковик, где кроме строки поиска еще куча рекламы и другой информации - любят ли пользователи такие поисковики? А ведь казалось бы, что сделать такую поисковую страницу с кучей автоматически генерящейся информации - это в разы сложнее и интереснее для программиста. А страницу гугла может сделать и школьник - никакого удовольствия. Та же проблема пронизывает всю работу программистов - они не любят делать простые удобные дизайны, а лучше сделают что-то супер расширяемое, хоть и неудобное. Они могут заставить пользователя сделать 5 кликов прежде, чем можно нажать кнопку “Сохранить” - и все это только потому, что “зато такой дизайн позволяет до ЛЮБОЙ кнопки добраться всего за 5 кликов” - но ведь пользователю не нужна “любая кнопка” каждые 2 минуты, а только нопка “Сохранить”.
3. Если вы хотите как-то улучшить ситуацию с ПО, то пишите про каждую найденную неудобность и недоработку разработчику. А если разработчик не реагирует, то на публичные форумы. Например, если на каком-то сайте что-то не работает или работает, но неудобно, то найдите форму обратной связи и напишите там свои впечатления. Если MS Office глючит или новый интерфейс вам не нравится, то найдите там кнопку Send Feedback и напишите про свои впечатления. Это кажется неважным обычно, но на самом деле это единственный канал, по которому разработчики могут узнать, что в программе или сайте что-то не так. Представьте, что Майкрософт поменял интерфейс в MS Word и новый интерфейс никому не нравится, но никто не шлет отрицательные комментарии. Изменится ли что-то? А если каждый из 100 млн. пользователей напишет отрицательный feedback? То же самое относится и к любому сайту, к любой программе - не ленитесь слать фидбек разработчику. А если вы разработчик, то не ленитесь сделать посыл фидбека максимально простым, ведь улучшение продукта - это в ваших интересах

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


P.S.:
А вот она и на русский переведена уже, оказывается: Дэвид Платт. Софт - отстой! И что с этим делать?. Рекомендую.


Понравилась статья? Подпишись на RSS!

Любой проект - это море общения.

Общение - это далеко не только разговоры девелоперов на кухне, но и практически любая другая проектная активность:

• Документация. Написание и чтение оной. Это общение, так как писатель “общается” с читателем посредством документации.
• Дизайн архитектуры приложения или конкретных фич. Это общение, так как архитектура и фичи не возникают в голове у одного человека. И даже после того, как они возникли - их еще надо донести до окружающих.
• Митинги, обсуждения, отчеты.
• Планирование работы, постановка задачи. Бывают ли планирования без общения? Возможно, да, в клинических случаях. Но постановка задачи - это уж точно акт общения.
• Занесение бага в баг трекер тестером, исправление бага программистом, проверка исправления тестером и т.д.
• Обучение, тренинги, посещение конференций и т.п.

Можно назвать еще много разных активностей, ведь практически любая активность на проекте связана с общением. Много вы можете перечислить активностей на проекте, в которых “общение” не играет никакой роли? Я не могу назвать ни одной.

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


А как достичь совершенства в общении?

А никак! Общение между людьми несовершенно по своей природе. Все люди разные, с разными представлениями об обсуждаемой проблеме, с разным уровнем знания, с разным настроением, наконец. То, что одному человеку можно объяснить двуми словами, другому вы будете объяснять полчаса. Фраза, полная сокращений и аббревиатур будет значить очень много для опытного разработчика, знакомого с предметной областью, но для новичка это будет просто набор бессвязных слов.

Если вы смотрите доктора Хауза, то можете вспомнить, как его команда ставит диагноз - они не тратят времени на обсуждение деталей. Они говорят скупые, понятные только им, как профессионалам, слова, дают ссылки на специальные случаи и прошлый опыт и всё - диагноз поставлен. Всего 30-40 секунд и “подходит. вколите ему хрензнаетчтонин”.


Как и почему это работает?

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

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


Рассмотрим вкратце разные виды “общения” и как их можно улучшить:

• Документация. Всегда надо точно представлять тех, кто будет читать документацию, которую вы пишете. Если вы пишете для специалистов, для Senior Developer, тогда вы можете использовать совсем другие слова и гораздо меньше текста, чем если вы пишете для начинающих. Документация для начинающих должна содержать гораздо больше информации и не должна содержать аббревиатур или общепринятых в компании терминов, которых начинающий может и не знать пока. Разберитесь вначале, кто  будет читать ту документацию, которую вы собираетесь написать и пишите в подходящем стиле. Не требуйте писать документацию “для начинающих”, если начинающие не будут ее читать. И не сажайте начинающего писать документацию для специалистов.
• Дизайн архитектуры приложения или конкретных фич. Пригласите на обсуждение архитектуры половину Senior и половину Junior программистов и вы погубите проект. Обсуждение займет бесконечное число времени, так как вы будете тратить больше времени на объяснение понятий и теории, чем на, собственно, архитетуру. Собирайте только людей, находящихся на одном уровне понимания проблемы для обсуждения архитектуры. При этом под джуниорами я понимаю не только тех, кто только начинает работать, но и всех, кто Junior для этой конкретной обсуждаемой проблемы, кто не имеет опыта работы в этой сфере. Например, профессиональный программист с 10 годами опыта работы может быть Junior, если он попал на митинг в другой отдел и обсуждается то, о чем он понятия не имеет.
• Митинги, обсуждения, отчеты. Тут совет такой же, как в предыдущем пункте - не пытайтесь совместить людей с разным уровнем понимания проблемы на одном митинге. Если вы хотите все же задействовать Junior-ов в обсуждениях, то соберите вместе 5 джуниоров и 1 senior - этого может быть достаточно.
• Планирование работы, постановка задачи. Знайте уровень, на котором нужно планировать. Для Senior достаточно написать краткое описание задачи (User Story) и всё - дальше он все спланирует сам. А для Junior нужно написать детальный план. Но если вы будете тратить время на написание детального плана для Senior, то это как раз и есть неэффективность общения.
• Занесение бага в баг трекер тестером, исправление бага программистом, проверка исправления тестером и т.д. Если программист и тестер работаю вместе не первый год, то у них свой язык общения. Они могут описать сложнейший баг одним простым предложением и ссылкой на похожий предыдущий баг. Исправление и инструкция по перепроверке может быть такой же короткой. Так что не разлучайте людей, давно работающих друг с другом.
• Обучение, тренинги, посещение конференций и т.п. Не посылайте начинающих на конференции для профессионалов - им от этого не будет толку. И не посылайте Senior людей на тренинги про основы Python или т.п. Также сильно разочаровывает, когда на одном и том же тренинге собираются сотрудники с разным уровнем знаний - им очень сложно понять друг друга и это приводит больше к раздражению друг другом, чем к правильному результату.

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


Понравилась статья? Подпишись на RSS!

А теперь шок: если верить википедии, то весь бюджет Нигерии (построенный на продаже нефти) всего раза в 2-3 больше этой суммы! Нафига нигерийцам вообще торговать нефтью, если у них есть такой выгодный источник дохода, как “нигерийские” письма? Легализовать их и писать их всей страной и всё - проблема нефтяной зависимости экономики решена в пользу более современной “зависимости”


Правда, уже сейчас рассылкой этих писем занимается больше 250 тыс человек, большинство из которых живет в Нигерии! 250 тыс! В России исследователи нашли 6 действующих «нигерийских» группировок, в состав которых входят более 50 человек (по предположительным оценкам 280).


Еще интересный и ожидаемый при таких масштабах прибылей факт:

Ultrascan отмечает, что международным центром отмывания денег, помимо Греции, теперь является Малайзия, конкретно — ее столичные банки. Зачастую «нигерийцы» оказываются владельцами национальных представительств Western Union или Moneygram. По консервативным оценкам, около 10% таких агентств осознанно пособничают скамерам, получая от них дивиденды.

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



Так что “нигерийские” письма - это глобальная проблема. Этот вид мошеннечества растет на 50-100% в год и уже через пару лет “доход” от такого рода деятельности может обогнать, например, доход всей игровой индустрии или даже киноиндустрии.


При этом риски от занятия этим родом деятельности равняются нулю - нет ни законов ни органов, которые пытаются противодействовать этому виду мошенничества. Насколько я понимаю, из 250 тыс. участников за все время не был арестован никто!

Если вы работаете в средней или крупной компании, то вам наверняка знакомо ощущение беспомощности, когда куча входящих емейлов, постоянные митинги, обсуждения, согласования и т.п. ерунда просто мешает выполнять реальную работу. Когда за несколько дней не получается написать ни строчки кода, зато получается отправить 20-30 емейлов и посетить 5-10 бесполезных по сути митингов и докладов. Когда (при достаточной вовлеченности) берешь домой ноутбук и начинаешь работать дома, чтобы хоть что-то сделать.
Эта проблема существует везде и многими даже не осознается, как проблема. Например, я встречал команды, которые в свои планы просто забивали “30% оверхед от митингов”, но даже этого оказывалось мало, т.к. программист - существо тонкое и, вырвав его из контекста, вернуть его обратно иногда не получается аж до конца рабочего дня. Так что “30% оверхед от митингов” превращался в “40% оверхед от митингов” через месяц, а потом и в 50%. И это, естественно, не решало никаких проблем, а только позволяло закрывать глаза и узаконить чудовищный under commitment (under commitment - это когда человек или команда обещает сделать заведомо меньше, чем может).


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

У коммуникации в большой компании есть 2 аспекта:
1. Если ты не будешь ничего никому сообщать, то никто не будет работать эффективно, т.к. никто ничего не знает. В клинической форме такое врядли встречается. А вот недостаток информации - это частый источник проблем. Например, когда один программист увольняется и целый кусок кода или даже весь продукт становится “черным ящиком”, в котором никто ничего не понимает. Или когда геймдизайнер в игре пишет дизайн документ и его никто не читает, а программисты параллельно пишут игру и в нее никто не играет, а художники рисуют графику и никуда ее не подставляют и все они видят игру по-разному. В итоге в момент сведения всего этого воедино получается православная компьютерная игра.
2. А если ты будешь сообщать всё всем, то никто не будет работать эффективно, т.к. все будут только и делать, что поглощать информацию. Опять же в клинической форме не встречается, но в близкой к клинической наверняка. Например, близко к клинике, когда по громкой связи на всю компанию объявляют о том, что кто-то кому-то звонит и просят взять телефон на линии 1. Или когда на всю компанию идет емейл рассылка с обсуждением сорта кофе, который закупить на следующий год (и поверьте, такая рассылка получит сотню комментариев, которые уйдут тоже в общий лист рассылки на всю компанию). Примеры можно приводить бесконечно.


Общая идея проблемы с общением очень проста.
Когда в компании работает 2 человека, то между ними есть только 1 связь. Если 3, то уже 2 связи. Если 4, то уже 6 и так далее. Между 10 человеками уже есть 45 связей и если каждый должен обсудить каждую деталь со всеми остальными, то это катастрофа. А для 45 человек (небольшой такой отдел в большой компании) число связей переваливает уже за 1000!
Заставь каждого из 45 человек согласовывать каждое свое решение со всеми остальными и ты получишь совершенно неработоспособный отдел - никто не будет принимать решения, а будут только обсуждать.
Кто не верит - есть отличный пример из реальной жизни от Microsoft: Как делали меню в Vista (я бы назвал это “200 строчек кода за год”).


В большинстве своем все программисты, да и другие сотрудники IT компаний, всегда стремятся получить информацию обо всем. Спроси любого: “Я тут сдизайнил новый вид нашего сайта - хочешь заценить?” и получишь ответ “Конечно!”. Спроси у другого “У меня есть идея, как сделать новую фичу в наш продукт” и получишь ответ “Не надо дизайнить это в одиночку - давай соберемся все вместе и все обсудим”.
Из этих вопросов и ответов видно, что люди готовы работать и даже делать то, что их вообще не касается. Они готовы обсуждать дизайн сайта целый час напролет даже если нифига не понимают в дизайне и считают, что лучший дизайн на сайтах bash.org.ru и linux.org.


Проблема еще усугубляется, когда что-то идет не так и люди начинают ощущать страх. Страх потерять работу, страх получить плохую оценку от менеджера или коллег, страх сделать что-то не так. Страх не заставляет людей работать эффективнее. Как раз наоборот - страх заставляет людей тратить время на внешнюю защиту. Испуганные сотрудники начинают посещать все подряд митинги, чтобы “не дай бог что-то важное не пропустить” и “еще разочек засветиться и что-то умное сказать”. Испуганные сотрудники созывают бесполезные митинги, куда приглашают как можно больше важных людей, чтобы показать всем, что работа движется и разрешить какую-нибудь небольшую проблему. Испуганные сотрудники мешают остальным работать, так как просто требуют все документировать и согласовывать с ними, ибо “иначе они ничего не могут обещать”.
Вообще, испуганные сотрудники - большая проблема для компании. Их легко создать, начав наказывать направо и налево за минимальные провинности, зато убрать страх из сотрудника и вернуть его доверие потом уже очень и очень сложно.


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


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


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


Новая статья Джоеля Сполски на эту же тему: A Little Less Conversation

Понравилась статья? Подпишись на RSS!