Есть в Рунете такой подкаст: DevZen. Я его практически никогда не слушаю. За исключением некоторых отдельных случаев: один раз там обсуждали именно что мой пост в моем блоге, один раз там говорили про модный и молодежный взгляд на ООП вообще и ООП в C++ в частности, один раз обсуждали акторов в C++, один раз послушал фрагмент DevZen с участием Григория Демченко и пара выпусков про Лондон и стартапы. Хотя ссылки, которые там накидывают в комментариях стараюсь просматривать, бо временами встречается интересное.
Не слушаю подкат по нескольким простым причинам. Во-первых, сам формат подкастов мне не нравится, прочитать текст для меня гораздо удобнее, чем слушать двухчасовые разговоры (в дороге на работу я провожу мало времени, так что время на прослушивание нужно выкраивать из других активностей). Во-вторых, темы DevZen поднимает такие, которые меня самого мало волнуют и мало касаются. В-третьих, очевидно существует некий возрастной разрыв: то, как ведут себя ведущие подкаста, способы обсуждения и способы общения мной уже воспринимаются как типично молодежные. Может быть, будь мне лет на 15 поменьше, меня бы все устраивало. Но сейчас хочется чего-то более степенного, размеренного, вдумчивого, без навязчивых и настойчивых попыток донести свою точку зрения. Но, повторюсь, это лично мои стариковские заморочки.
Намедни в DevZen заглянул некто Егор Бугаенко. Я хз кто это такой и чем он знаменит. Но что-то последние пару лет это имя слишком часто всплывает в этих наших Интернетах, дай, думаю, послушаю, приобщусь. Выкроил часок, послушал. Получил некоторое впечатление, которое имеет две или даже три составляющие:
Во-первых, в очередной раз горячая кровь молодых ведущих дала о себе знать и временами разговор с гостем напоминал попытку объяснить гостю, что он делает свою работу неправильно. ИМХО, конечно. Но конструктива, т.е. попыток вытянуть из гостя больше деталей и больше правды вместо маркетинга, было меньше, чем попыток рассказать, насколько важно общение в проектных командах. Плюс конструктив был сконцентрирован ближе к концу плотного расспроса Егора, когда сложилось впечатление, что у большинства ведущих уже просто не было желания что-то кому-то еще раз доказывать.
Тут мне вспоминается "Человеческий фактор" ДеМарко и Листера. Там была глава, а может и не одна, в которой авторы объясняли, почему нет "волшебной пилюли", т.е. нет какой-то технологии или процесса организации работы, который бы подходил всем и всегда. Все работает и все не работает. Т.е. для любой идеи можно найти условия (и примеры из жизни), в которых идея покажет отличные результаты. И для этой же идеи можно найти условия (и примеры из жизни), в которых идея приводит проекты к краху. Не суть важно, идет ли речь о языке программирования, фреймворке или организации труда. В одном месте процесс waterfall работал, работает и будет работать. В другом месте с waterfall вы потратите кучу денег, времени и сил, но ничего не достигнете. Точно так же и с каким-нибудь Agile: в каких-то командах на каких-то проектах методология SCRUM будет работать хорошо, в каких-то не будет работать вообще.
Так что нет ничего удивительного, что у Егора Бугаенко бизнес работает по правилам, которые кому-то кажутся странными и противоречащими здравому смыслу. Ну вот работает так. Если это вызывает удивление, то, на мой взгляд, более продуктивно было бы задасться другими вопросами. Скажем, а можно ли вообще считать компанию Егора Буганеко успешной? Может быть текущий рабочий процесс устраивает самого Бугаенко и тех, кто на него работает, но с точки зрения прибыльности, финансовой устойчивости и пр. параметров, сам бизнес находится где-то на грани выживаемости?
И только если на первый вопрос был получен положительный ответ, можно было бы разузнать больше об условиях, в которых этот неоднозначный процесс работает. Что за проекты, какова их специфика, каковы строки, каковы требования клиентов, как происходит взаимодействие с клиентами, как происходит формализация этих хотелок, кто эти занимается, как и в каком виде эта информация доносится до разработчиков, как и кем происходит валидация вектора движения проекта (т.е. кто определяет, что делается именно то, что нужно клиенту), что делать, если требования клиента меняются и т.д., и т.п.
Весьма вероятно, что тогда открылось бы много интересных подробностей.
Во-вторых, я так и остался в неведении, кто такой Егор Бугаенко и почему вокруг него столько шума. Такое впечатление, что это бизнесмен, который смог построить небольшой аутсорсинговый бизнес. И который создает PR своему бизнесу через PR самого себя посредством эпатажа почтенной публики. Где-то этот эпатаж заключается в разговорах о том, что народ ООП готовит неправильно. Хотя хз, насколько сам Бугаенко в курсе того, что из себя ООП представляет вне мира Java. Где-то этот эпатаж заключается в том, чтобы рассказать о ненужности общения между разработчиками в проекте.
Так что нельзя не признать, что в плане PR-а Егор Бугаенко работает просто отлично. На мой взгляд.
Хотя это такой PR, который будет работать только для отдельных личностей. На себя подобную технологию PR-а проецировать, имхо, весьма опасно.
В-третьих, меня лично описанная технологии разработки не впечатлила. Есть ощущение, что все это работает, потому что:
- Это аутсорс. На аутсорс безопасно отдавать рутину, небезопасно отдавать ключевые для бизнеса вещи. Сложность же, как правило, как раз в ключевых вещах. А как разрабатывать ключевые продукты или ключевые части продуктов без нормального общения и "перекрестного опыления", которое возникает в спорах и при тесном контакте сотрудников, я не очень понимаю. Напомню, например, такую штуку: Джо Армстронг, автор языка Erlang, одним из основных факторов успеха в реализации AXD 301 в Ericsson-е считал то, что вся команда разработчиков ядра AXD 301 была собрана в одном месте.
- Это небольшие проекты с небольшим временем жизни. Ну, в самом деле, если проект длится год и в нем порядка 100K строк, то это совсем другие масштабы, чем когда проект длится 10 лет и содержит 1M строк. Кстати, о цифре в 100K строк. Есть мнение, что нормальная выдача программиста -- это 100 отлаженных строк кода в день (для простоты возьмем, что это 100 строк для языков вроде Java, C++ или C#). Понятно, что человек может два дня ничего не написать, затем за день написать и отладить 300 строк. Но в среднем 100 строк и выйдет. Что означает, что в месяц продуктивность будет составлять порядка 3K строк. Возьмем 11 рабочих месяце в году и получаем 33K строк от одного программиста. Т.е. на проект в 100K строк за год потребуется 3-4 разработчика. Понятно, что это сильное упрощение и в жизни все не так гладко, затрат будет гораздо больше, но все-таки 100KLOC за год -- это совсем не так сложно и тяжко, как это может звучать в подкасте.
- В команде есть изрядное количество людей, предпочитающий эпистолярный жанр общения. И, что немаловажно, умеющий это делать. Мой опыт говорит о том, что правильно и (что важно) вежливо донести в письменном виде идею гораздо сложнее, чем в устной речи, особенно при общении лицом к лицу. Ведь в письме сложно передавать интонации, письменный текст выглядит более категоричным и агрессивным, пишущий не имеет возможности просто так определить, совпадает ли контекст обсуждения у собеседников, или же у говорящего одна картина мира в голове, у слушающего -- другая. Как по мне, так набрать такое количество людей, умеющих быстро и точно доносить суть в письменном виде, гораздо сложнее, чем набрать достаточное количество хороших программистов, умеющих писать простой и надежный код.
С другой стороны, в разговоре мне не хватило подробностей, чтобы выяснить, в каких же условиях описанный подход работает. Ну или считается работающим. А вот пробовать на своей шкуре что-то подобное желания нет. Ибо есть опыт. Мы с коллегами часто общаемся только через почту, но тем не менее, обязательно считаем нужным хотя бы пару раз собраться в офисе, поскольку без очных встреч и разговоров очень сложно сохранять общее направление движения и корректировать курсы.
В общем, что в сухом остатке? В сухом остатке две цитаты из "классиков":
- "И — боже вас сохрани — не читайте до обеда советских газет."
- "...верить в наше время нельзя никому, порой даже самому себе. Мне — можно."
;)
Комментариев нет:
Отправить комментарий