Category: Управление

Закон Конвея

Я все время забываю формулировку закона (правила?), а гуглится он почему то очень плохо, так что запишу его тут. Итак, Джон Конвей когда-то заявил что:

Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

что можно перевести как:

Организация которая разрабатывает систему ... вынуждена делать систему по структуре повторяющую структуру коммуникаций внутри организации

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

Причем если эти команды тесно общаются, например устраивая ежедневные skype митинги и вообще, то и модули будут тесно связаны — например единая сборка, репозиторий, документация, трекер, но разные библиотеки лежащие рядом. Но если общаются лишь переписываясь по email, то получите связь через какой нибудь RESTful API. Десятки раз видел подобные примеры.

Или, как сказал Эрик Реймонд:

Если у вас есть 4 команды разрабатывающие один компилятор — вы получите компилятор работающий в 4 прохода (4-pass compiler)

См. закон на википедии: Conway's law

Как запускался Groupon и как проверялась идея


Говорят что первая версия групона была лишь наскоро запущенным блогом, на стандартном wordpress. Для покупки купона надо было отправить емейл, на указанный адрес. Он вручную обрабатывался, и присылался PDF с кодом. А для генерирования этого PDF была найдена какая-то примитивная программа.

Когда авторы убедились что модель работает (письма шлют/соседняя пиццерия довольна) — тогда и началось развитие. Если бы увидели что не заработало — на этом все и закончилось бы. Вот так просто, потратив пару дней, можно проверить жизнеспособность идеи. Лучше чем тратить несколько месяцев на продукт, основываясь лишь на своей интуиции.

PS Само отношение к groupon у меня не изменилось, но перед такими вещами снимаю шляпу, молодцы.

Hirelite — собеседовние в форме speed dating

Hirelite несколько оригинально организует поиск работы / подбор персонала: в виде speed dating. В данном случае это когда в одном месте собираются несколько компаний которые ищут работников, и несколько человек которые ищут работу. Садятся попарно — 5 минут на рассказать о себе и послушать что ищет компания. Если интересы совпали — то тогда добро пожаловать на полноценное собеседование. Итого пару часов вечером — и все довольны. К томуже проводится через вебкамеру (но, конечно, с четкой привязкой к городу/месту работы)

И да, в данном случае поиск работы/работников в сфере ИТ, а именно для программистов.

Надо быть чуть ленивым

В книге The Lazy Project Manager есть небольшой фрагмент о том как Хе́льмут Карл Бе́рнхард фон Мо́льтке, германский генерал позапрошлого века, отбирал офицеров. Он разделил офицеров по двум критериям: умный-глупый и ленивый-энергичный.


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

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

PS нет, сама книга не про то что нужно во всем лениться, это лишь часть идеи, название не совсем корректное

Несколько лет назад я удосужился поработать в Люксофте

Но с ними как то совсем не срослось, и ведь только сейчас я понял почему. И на тот момент тоже казалось бы было куча причин почему там плохо: индусские проекты, низкая зарплата и пр., но это, на самом деле, не главное. Сейчас я понимаю что я не смог работать в условиях когда моя работа ничего не значит. Люксофт ведь это конвейер, CMMI, тут главное четкое следование процессу, и ни в коем случае не личная инициатива. Как огромный танк, или комбайн, если угодно, он движется к завершению проекта, и не важно как.

А я так не мог. Я из тех кому нужно проявиться инициативу, кому хочется быть шеф поваром в ресторане, а не «менеджер» в макдональдсе. Но что интересно, большинство предпочитает прямо противоположное. Я хоть и не приемлю такую работу, но с точки зрения психологии я понимаю, это вполне объяснимо, и подавляющему большинству это подходит лучше всего. Как и люксофту, с другой стороны.

Надо это как то тоже учитывать.

Работа, деньги и мотивация

Встретил эксперимент по поводу мотивации и ее связи с оплатой труда, который мне показался адекватным и заслуживающим внимания. Точнее это была пара эксперементов, на тему «сизифова труда». Студентам предлагали простую работу: собрать робота из Lego, или найти в тексте определенные сочетания. За каждый результат платили, но при этом они работали в разных условиях. В одном случае их работа уничтожалась тут же, на глазах. Робота разбирали через секунды после того как студент его собрал (т.к. нужны были детали следующему студенту), а обработанный текст отправляли в уничтожитель бумаги, не читая.

С другимим студентами так не издевались, собранный ими робот оставался на столе собранным до окончания эксперимента, а результат обработки текста смотрели, требовали указать фамилию и откладывали отдельно.
Continue reading

Еще к вопросам на собеседоваии

Меня там все переубеждают в «Вопросах на собеседовании», вот наконец-то появился момент написать ответ.

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

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

Ну и позволяют выяснить когда человека «вообще ничего не знает». Главное не обобщать, не спутать с человеком который не знает «конкретную реализацию конкретного класса в конкретном языке программирования».

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

Вопросы на собеседовании

Всегда не понимал вопросы на собеседовании из серии «а какие методы есть у класса Object?», «в чем отличия left/right outer/inner join'ов». Для чего нужны такие вопросы? Какие выводы можно сделать из ответов? Ну вот ответил кандидат, и что? Он хороший программист? Не ответил — плохой? Я не понимаю какой вывод можно сделать. Наверное спросить можно, но лишь к слову. Но еще интересней вопросы из серии «чему будет равен логарифм по основанию 2 от 10 миллионов». Это вообще к чему???

Я не вижу смысла задавать вопросы, на которые можно получить ответ задав один очевидный запрос в гугле и получит ответ в первых 3-4 ссылках.

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

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

Имхо это некоторое сочетание из (помимо знания конкретной технологии):

  • абстрактного мышление
  • наличия своего мнения
  • умения продумать на шаг вперед
  • общего кругозора и знакомства со смежными областями
  • увлеченности

Что я забыл? И как все это проще всего выяснить?

90% разработки

Есть такое интересное разбивание проекта на этапы, как я называю «по правилу 90%». Я не знаю откуда я его взял, может где-то прочитал, может сам это вывел, может еще что-то, но тем не менее:

  1. Команда рано или поздно приходит к моменту когда проект «уже сделан на 90%» — что-то уже запускается (в идеалистичном use case) , есть какая-то система, казалось бы осталось лишь допилить чуть чуть.
  2. Но на самом деле это лишь начало. Дальше еще столько же до того момента когда продуктом можно будет реально пользоваться, когда он станет работать у другого человека, перестанет падать в ситуации отличающейся от идеальной и т.д. Вот тут да, снова дошли до стадии «готово на 90%».
  3. И это оказывается не все... 🙁 Теперь нужно допилить чтобы все было «красиво», удобно, чтобы это поддерживалось, запускалось из коробки, были написаны инструкции. И после уже снова «готов на 90%», тут уже и правда почти готово.

Continue reading

Конфликты команды разработчиков

В предыдущей заметке про психологические роли разработчика я сказал что они явно конфликтуют друг с другом, и я утверждал что это конфликт очень важен. Т.е. я вообще сторонник того что конфликт это нормально, он нужен, если его видеть, правильно понимать и направлять на благо компании и его участников. А если нет конфликта, и два человека полностью согласны во всем друг с другом, имеют один взгляд во всем, то зачем нужен второй человек?
Continue reading