суббота, 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-а у меня оказалась: "Про отчет "менеджера" об использовании Хаскеля".