суббота, 22 февраля 2014 г.

[prog.management] Вывод из жизненных наблюдений за совместимостью производственной культуры и стилей управления

Нельзя выходца из большой софтверной компании ставить руководителем разработки в маленькой софтверной компании. В особенности выходца из прогоревшей и поглощенной (или развалившейся) большой софтверной компании.

Объяснение очень простое. Успешное функционирование большой компании сильно зависит от формализованности процессов. Рядовые сотрудники в прямом смысле должны быть взаимозаменяемыми винтиками.

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

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

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

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

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

Про выходцев из прогоревших больших софтверных компаний, полагаю, не стоит долго объяснять. Они будут насаждать процессы, которые не сработали. На совершенно другой почве. Как вы думаете, какова вероятность, что все пройдет хорошо?

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

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

[life.photo] Так ли уж интересно быть фэшн-фотографом?

PhaseOne делает хороший софт для обработки фото (CaptureOne) и, полагаю, хорошие среднеформатные камеры. В рамках PR-а своей продукции они время от времени присылают ссылки на интересные видеоролики, в которых показывается использование камер/задников/софта PhaseOne. Один из последних, полагаю, может раскрыть глаза восторженным фотолюбителям и показать реальную работу профессиональных фотографов:

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

Еще одна составляющая: хороший цифровой задник от PhaseOne стоит порядка 40K USD, плюс сама камера, плюс три-четыре хороших объектива (а когда речь идет о среднем формате и о 50-60Mpx, то вряд ли стоит ожидать хороших результатов от посредственной оптики), плюс дополнительное хозяйство... В общем, вложить, минимум, 55K USD в оборудование и потом заниматься тем, чтобы удовлетворять хотелки арт-директоров и терпеть капризы моделей -- это, мне кажется, нужно иметь определенный склад ума.

среда, 19 февраля 2014 г.

[management.tools] Непонятка в Redmine

Вынужден сейчас искать инструментарий для ведения проектов, задач и занятости исполнителей на них. Разбираюсь с Redmine. Штука симпатичная, легковесная и более понятная, чем, скажем MS Project или JIRA с накрученными на нее плагинами. Но есть и неприятные или же пока просто не понятные мне вещи.

Например, похоже, задачи нельзя ставить в зависимости друг от друга. Т.е. нельзя указать, что задача #13 должна стартовать только после завершения задачи #12. Соответственно, если исполнение задачи #12 выходит из запланированных сроков, то должны поехать и сроки старта задачи #13. Такие зависимости элементарно проставляются в MS Project, но я не нахожу их в Redmine :(

В Redmine можно задать родительскую задачу. Но тогда Redmine начинает сроки выполнения родительской задачи автоматически высчитывать исходя из сроков выполнения всех дочерних. Поэтому не удается сделать задачу "Разработка" родительской для задач "Тестирование" и "Документирование", т.к. тогда сроки "Разработка" будут складываться только из сроков "Тестирование" и "Документирование", а на собственно разработку ничего не останется.

Заодно, чтобы два раза не вставать, вопрос к читателям: а чем вам приходится пользоваться для планирования, раздачи заданий, учета занятости сотрудников и т.д.? MS Project, JIRA, Hydra, Clarizen или какой-то другой зверь? Как впечатления?

Upd. По наводке ув.тов.blobtdp удалось найти возможность связывать задачи в Redmine:

понедельник, 17 февраля 2014 г.

[blog] Взял да и номинировал сам себя на itawards.by в категории "IT-блоггер"

Как зарегистрированному пользователю dev.by мне сегодня пришло письмо следующего содержания:

Привет!

Как вы, наверное, уже знаете, команда dev.by выступила организатором премии Belarusian IT Awards. Задумывая ее, мы ставили своей целью отметить вклад, который сделали участники белорусского ИТ-сообщества в развитие индустрии. Номинирование носит открытый характер — уже сегодня вы можете заявить достойного на ваш взгляд претендента на победу в любой из 20 номинаций премии. Это может быть компания, сообщество, продукт, евангелист технологии, блоггер или преподаватель. Этап номинирования продлится до 28 февраля. Ознакомиться со списком номинаций и предложить кандидатов на получение награды можно на сайте itawards.by.

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

Мы рассчитываем, что вы не останетесь равнодушными и номинируете лучших с вашей точки зрения. Просто кликните по подходящей номинации на itawards.by.

С уважением, команда dev.by

Зашел ради прикола, а там есть номинация IT-блоггер 2013. Ну и, думаю, почему бы и не поучаствовать. Взял да и номинировал сам себя. Теперь буду ждать, чем все закончится.

Кстати, самой популярной заметкой 2013 по статистике blogger-а у меня оказалась: "Про отчет "менеджера" об использовании Хаскеля".

суббота, 15 февраля 2014 г.

[life.photo] Прочитал книгу "Школа фотографии Майкла Фримана. Композиция"

Книгу "Школа фотографии Майкла Фримана. Композиция" купил вместе с кучей других книг по фотографии в середине прошлого года. Но руки дошли до нее только сейчас. Прочитал книгу довольно быстро. Текста там не много, зато много фотографий, иллюстрирующих слова автора. Это большое достоинство книги.

Еще одно интересное отличие книг серии "Школа фотографии Майкла Фримана" от других книг этого автора в том, что в ней Фриман местами разбирает фотографии своих учеников. И такие разборы иногда оказываются полезнее, чем текст предшествующей разбору главы. По крайней мере очень радуешься, когда твое впечатление от фотографии совпадает с мнением Фримана.

Что касается ценности книги, то для меня это уже очень сложный вопрос. На книги о фотографии Майкла Фримана я подсел по рекомендации Дмитрия "Гоблина" Пучкова. Книги, действительно, хорошие. В отличии от, скажем, Ицхака Адизеса, Фриман не опускается до копипасты своих собственных текстов. Фотографии хорошие подбирает. "Воды" льет не много, в основном пишет по делу. Но...

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

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

[prog.flame] Хорошая заметка о выборе языка для серьезного проекта от kaa.python

Ув.тов. Александр Ставонин (он же kaa.python) написал хорошую и интересную заметку "Как выбрать язык программирования для нового проекта". Я подпишусь практически под всем, что там сказано (правда, я бы поставил Ruby в один ряд с Python-ом, но это, скорее, мои личные эстетические предпочтения).

Однако, заметка вызвала несколько, возможно, спорных и неоднозначных мыслей, которые я решил зафиксировать здесь. Ну, дабы графоманство глупость говорящего видна была ;)

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

Полагаю, многие молодые разработчики, среди которых особенно много падких на привлекательность экзотики, никогда не читали "Человеческий фактор" ДеМарко и Листера. А зря. Это, вероятно, самая лучшая книга, рассказывающая об основополагающих принципах разработки ПО. И в ней этот феномен успешности первого применения нового инструмента разбирается "по косточкам". Причины успеха при разработке нового проекта на новом языке программирования определяются вовсе не уникальными возможностями инструмента. Основная причина успеха в самой новизне: само по себе использование нового языка дает мощный толчок, мобилизует разработчиков, заставляет напрягаться и стремиться к успеху. Но, когда ощущение новизны уходит и использование нового языка переходит в рутину, все возвращается на свои места. Только, если экзотика не перейдет в мейнстрим, компания окажется в худшем положении. Ибо кадры решают все, а вот с кадрами...

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

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

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

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

Значит ли все вышесказанное, что лично я против внедрения новых инструментов и языков программирования? Нет, не значит :) Но нужно понимать, что погоня за технологическими выигрышами от нового языка сопряжена с высокими рисками. И тут уж вам самим нужно решать, готовы вы рисковать. А заметки вроде этой лишь немного подсказывают степень риска и возможные негативные последствия.

За более подробной информацией на эту тему я адресую желающих к своей старой заметке, написанной более пяти лет назад, но не утратившей своей актуальности.

Ну а в завершении потока мыслей, вызванных заметкой ув.kaa.python выскажу два моих личных наблюдения о Java и C++ (при этом прошу учитывать, что Java я не люблю еще со времен ее выхода в 1995-м году, хотя при необходимости могу что-нибудь на Java изобразить; а языком C++ я с удовольствием пользуюсь уже более 20 лет):

  • из-за ущербности в своих выразительных возможностях Java заставляет писать больше кода чем на других мейнстримовых языках программирования. Следствием чего, если ваш проект на Java "взлетит", станет постоянный рост кодовой базы и постоянная необходимость увеличения проектной команды. Так что, при всем том, что Java удешевляет получение работающего решения (по сравнении с тем же C++), расплачиваться за это придется большой проектной командой, участники которой будут вынуждены работать с простым (на грани примитивности), но объемным кодом;
  • С++, напротив, имеет возможности делать нетривиальные вещи более компактными и выразительными (если сравнивать с Java). Поэтому, небольшая и сильная команда C++ников способна вести сложный проект на C++, аналог которого на Java мог бы требовать раза в два больше разработчиков. Но тут нужно понимать, что под сложностью понимается именно алгоритмическая и логическая сложность (например, сложные преобразования данных, хитрые структуры данных, изощренные алгоритмы, жесткие требования к ресурсоемкости и т.д.). Если же под сложностью понимается необходимость задействования в проекте целой кучи трех-четырех-пяти буквенных аббревиатур (вроде XML, HTTP, REST, SOAP и т.д.), то ситуация может оказаться прямо противоположной и десять Java-разработчиков легко будут делать работу двадцати C++ников.

Ну и совсем уже напоследок выскажу мысль о том, что по моим наблюдениям "за эфиром" (форумы, статьи, блоги и др. источники) сейчас такие языки, как Haskell и Erlang вполне можно считать мейнстримовыми. И, при наличии достаточного количества разработчиков для формирования проектной команды, я бы всерьез рассматривал варианты применение Haskell-я и Erlang-а наряду с Python/Ruby/Java/C#/C++. Правда Haskell бы я не выбрал из-за того, что чистая функциональность, имхо, вступает в противоречие с объективной реальностью, которую нужно выражать в коде. Ну и из-за некоторой неадекватности его адептов :) А Erlang -- из-за динамической типизации :)

PS. Блог я веду уже давно, понаписал за это время многого. Что дает возможность делать ссылки на самого себя :)
Отлично сказано! Так почему же самые продвинутые языки не попадают в мейнстрим?
Каким же образом знание разных языков делает программиста лучше?
Споры о языках программирования – не могу смолчать

вторник, 11 февраля 2014 г.

[bugs] Событие ожидается сегодня

Непрофессионализм сотрудников dev.by не перестает доставлять. Вот, из сегодняшнего, от 11 февраля, дайджеста: