ИТ вне формата

Кое-что про совещания...

Возможно, что боян. Но сильно улыбнуло...

 

Фраза недели

Коллега выдал: "Любой проект - это сделать из г. конфетку. Причем сроки - кратчайшие".

Добавлю к этому,  что все на вышесказанно обычно накладывается "нехватка прочих ресурсов".

Но при этом проекты делаются, и мы (проектные менеджеры) получаем свою долю "проектного драйва" :)

Про ключевых специалистов или как удержаться в компании.

В последнее время много работал, много думал, поэтому в свой блог писал мало. А еще меньше - в блог на IT Blogs. :-)

Сразу же оговорюсь: ниже речь идет о небольших компаниях. Относительно небольших: до 300..500 человек. Плюс-минус человек 200. И, разумеется, совсем не про публичные компании, тип Microsoft или SAP. Там, скорее всего, совсем другие законы.

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

В ИТ компаниях или ИТ подразделениях компаний эта проблема стоит еще более остро: ИТшник, особенно с головой, способен так "замутить"в коде/в настройках/в процессе/..., что распутывать придется долго-долго...

Несколько примеров (целиком авторская фантазия, хотя реальных похожих случаев я знаю немало):

• Ведущий разработчик корпоративной ИС, вокруг которого штат программистов... имеющих доступ лишь к GUI интерфейсам и знающих имена функций, которые они должны вызвать, и параметры, которые нужно передавать.
• Системный администратор, который обслуживает сеть из n ПК и m серверов. Вокруг него (возможно, постепенно) появляется штат "помощников" - так называемых "эникейщиков", которым со временем передается "не основное": ввести пользователя в домен, заменить картридж... в общем, все, кроме доступа к серверам с корпоративной ИС, роутеру, раздающему Интернет и заведующего удаленным доступом.
• Начальник отдела/группы/сектора/..., фактически - "играющий тренер", на которого "завязан", например, участок работы... пусть будет построения внешних сервисов для клиентов компании. При этом у него есть сотрудники, каждый из которых отвечает исключительно за свою работу и не смотрит за "работой товарищей". То есть получается "двойная страховка": с одной стороны на уровне распределения работ ("общая картина" завязана на одного человека), с другой: самостоятельная разработка отдельного модуля (разработка завязана на одного человека - ситуация рассмотрена выше).
  

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

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

Как-то невесело получается...

PS. Это я не про свою работу, это я вообще... о жизни.

Работодатели сошли с ума?

Недавно (скорее по привычке) читал себе hh.ru - что нового и как оно подается. Может быть, это мне так "повезло", но создалось впечатление, что работодатели начали сходить с ума. Навскидку (если "выжать суть") имеются следующие поразившие меня вакансии:

• Менеджер проекта (с весьма серьезно расписанными обязанностями - то есть менеджера и аналитика в одном флаконе), с дополнительной "повинностью" - поддержка работоспособности сети из 15ПК. Явно тут кто-то чего-то скрывает...
• Менеджер проекта, который сравнивается с су-поваром, в распоряжении которого поварята и прочий "кухонный люд";
• Директор коммерческий, который судя по вакансии, будет являть собой коммерческий отдел "в одном флаконе", со "стартовой заработной платой" в 40 т.р.

Там было еще что-то не менее любопытное, дочитывать не стал. (Ремарка: все компании - некрупные. "Гранды" и "монстры" ни в чем подобном уличены не были).

Если серьезно, то после прочтения страниц 10 вакансий, сложилось такое ощущение, что либо

1. Специалистов нет. Вообще, и хочется привлечь их любыми средствами (но при этом очень хочется сэкономить);
2.  Работодатели пытаются вводить "новые методы" для поиска кандидатов;

Программист-потребитель, программист-гений...

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

• Программист-гик. Человек, которому интересно. Действительно интересно то, чем он занимается. Мозг постоянно требует новых задач, душа - творческих свершений. Если задача интересная сделает ее быстро - потому что интересно. Если не интересная - быстро, чтобы осталось время на интересную. Может "зарыться" на сутки в кодирование, решая пустяковую (давно решенную) задачу каким-нибудь нестандартным образом. Четкую постановку задачи не приветствует. Много знает. Умеет еще больше. Готов прийти на помощь, но часто не приемлет помощь других. Болезненно относится к критике. Может "жить" на работе, если интересно. Или наоборот - "положить" на работу, если не интересно. Документации не ведет в принципе. В команде работать может. А может и не работать :)  "Завалить" работу может запросто. С позиции управленца требует внимания и контроля, а также постоянного "приземления".
• Программист-профессионал. Человек, который понимает - чем и зачем он занимается. Требует четкой постановки задачи, готов разбираться в прикладной области, генерировать идеи, делиться идеями. Как правило, не задерживается на работе, предпочитая планировать на какой-нибудь срок вперед. Тем не менее, сроки выдерживает практически всегда. Много знает, и много умеет. Критику принимает. Вариант с "завалом" работы может произойти только если его перегрузить работой. В процессе разработки составляет спецификации и старается документировать сделанное. Самодисциплинирован. В команде, как правило, работать может хорошо. С позиции управленца - один из оптимальный вариантов: не требует слишком много времени на постановку задачи и выдает отличный результат.
  
• Просто программист. До "профессионала" явно не дотягивает - не хватает знаний/стажа. Дальше возможны варианты:
• Позитивный: работает над собой, стремясь во что бы то ни стало расширить свой кругозор, и стать профессионалом. Учится работать в команде, иногда не забывая документировать сделанное. Учится работать в команде. Для управленца - нормальный вариант: через некоторое время из него может вырасти профессионал.
• Негативный. Работает "спустя рукава", единственный мотиватор - зарплата, большого желания работать над собой не наблюдается, зато всегда готов обосновать, почему именно он не должен решать ту или иную задачу. Для управленца: головная боль - вроде и не нулевой выхлоп, но сил и нервов тратится... не дай Бог.
  
• Программист начинающий. Тут тоже возможны варианты.
• Программист-стажер (студент): вариант А. Вопреки распространенному мнению ("студенты -дешевы и халтурят") студенты вполне способны выдавать и хороший результат, и работать в команде. Просто, если человек хороший :) то у него со временем все начинает получаться. С точки зрения управленца - вариант интересный: есть шанс, что вырастет профессионал.
  
• Программист-стажер - не на своем месте. Как известно, студенты - это люди, которые стремятся найти дополнительный заработок. Вот и идут - в том числе в программисты. Кто-то их берет, и они пытаются приспособиться к тому, к чему физически не предрасположены. Самое неприятное, что, если им вовремя не остановиться, то через некоторое время это будет негативный вариант "просто программиста". С точки зрения управленца: не вариант.
  
• Программист-самоучка. Как правило, либо непризнанный гений (худший вариант), либо разновидность того, кто описан в выше и ниже. Дело в том, что программирование - область специфическая, и в ней встречаются те, кто по образованию от программирования можетбыть весьма и весьма далек...
  
• Программист-кодер. Сугубый исполнитель. И этим сказано все. Требует готовых алгоритмов, готовых решений. К самостоятельной работе приспособлен слабо - может лишь перевести понятный алгоритм в код. И все. С точки зрения управленца: при наличии хороших постановщиков задачи такие люди нужны, в противном случае больше времени уйдет на то, чтобы объяснить им, что они должны делать.
  
• Программист-пользователь. Еще его называют "кулцхакер". Программист, неспособный самостоятельно поставить среду программирования :) И это - диагноз. С точки зрения управленца: не стоит даже связываться.

Вот как-то так получается.

Принцип корпоративного футбола

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

Соответственно, следующий товарищ передает пас дальше, получивший - передает в свою очередь... и так, пока не возвращаемся к исходной точке.

Кстати, не все так плохо. Разорвать круг пасов можно, если

• попасть на вменяемого человека;
• заручиться поддержкой вышестоящих;
• иметь вес в компании достаточный для того, чтобы стимулировать сотрудника сделать желаемое/необходимое;
• объяснить конкретному человеку его интерес (в том числе в виде наказания за бездействие);
• договориться по принципу "ты - мне, я - тебе" (разновидность предыдущего пункта);

"Вот так как-то":)

В тему запрета скайпа

Как известно, сотовые операторы пытаются через Гос.Думу запретить использование скайп. Вот вычитал в тему:

На повестке дня Государственной Думы:
1. Запретить Скайп по просьбе сотовых операторов.
2. Запретить сотовую связь по просьбе телефонных компаний.
3. Запретить телефоны по просьбе почты.
4. ...

(с) www.anekdot.ru/

О некоторых странностях в резюме

Периодически мне попадаются разного рода резюме. Толковые и не очень, структурированные и бессистемные - как придется.

Но! Что меня всегда напрягало, так это резюме двадцати- двадцатипятилетних ребят с заголовком типа "Руководитель проекта. Руководитель службы. Аналитик. Сотрудник helpdesk". Или " Руководитель. Ведущий разработчик. Системный администратор". Напрягает то, что человек не может определиться - кто он, действуя по принципу: "авось возьмут, а там разберемся". Если к этому прибавит  небольшой опыт, или его отсутствие, то становится понятно, что на позицию "руководитель" человек замахивается явно рано; здорово, конечно, что имеются амбиции и т.д., но работодатель нынче тоже вроде разборчивый пошел - и готов рассматривать на позиции "руководитель" как правило, человека состоявшегося, имеющего реальный (и желательно - подтвержденный, то есть проверяемый) опыт, прием на работу которого обеспечит хоть какую-то гарантию результата (решения поставленных задач). С другой стороны, рассматривать такого кандидата на роль специалиста также боязно: ну, есть такой человек, ну, претендует на все сразу - а каков он в деле? Где гарантия того, что он будет решать поставленные перед ним задачи, а не заниматься подогревом собственных амбиций, что, безусловно, проигрышный вариант: непризнанные гении - головная боль практически любого руководителя, который с ними столкнулся.

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

Причем мне почему-то кажется, что сказанное выше смело можно отнести не только к ИТ...

Вот такая вот история

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

Ляпота :)

PS. Почти никто не возмущался. Привыкли?

Никто не подскажет...

Коллеги, никто не подскажет хорошего генератора отчетов (не Crystal, open source весьма приветствуется)?

ReBrain Ring на SPB CIO Summit 2009 "Белые ночи"

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

Итак, попал я на CIO Summit благодаря Максиму Белоусову - как участник ReBrain Ring "Игры разума", проводимое на тему "Коммерческое ПО VS Свободное ПО". Основной вопрос, который дебатировался - "За каким ПО - коммерческим или свободным - будущее в России?".

Шоу проводилось в том же формате, что и телевизионный прототип. Капитаны-эксперты - Михаил Елашкин и Максим Белоусов. Михаил представлял коммерческое ПО, Максим - свободное. Я был в команде Максима, одним из двух секндантов :) Кстати, в команде Михаила тоже был автор ITBlogs - Марианна Крель. В общем, как говорится - "ну вот мы и встретились".

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

В итоге - победила дружба. Со счетом 2:1 в пользу Максима :) Хотя, с учетом приведенного выше вывода, мне это показалось не самым важным. Важно было то,ради чего и задумывался CIO Summit - общение. 

Боян, но задело :)

Повезли на стрельбы связистов. Отстрелялись они и по итогам распекает их командир. Такие вы значит сякие, стрелять не умеете, почти ни одного попадания. А связисты и отвечают: "Командир, с нашей стороны все пули ушли, так что проблемы на вашей стороне"

Жизненно? :)

Конференция "Лицензионное программное обеспечение - это просто и безопасно"

Сегодня принимал участие в конференции-выставке "Лицензионное программное обеспечение - это просто и безопасно". В качестве выступающего на круглом столе по теме "Open Source и лицензирование ПО. Свободное программное обеспечение и коммерческие решения. Возможности и ограничения".

Рассказывал про Open Source и возможности применения свободного ПО для решения бизнес-задач. Кому интересно - презентация во вложении к этому посту.

Вкратце основная идея такова: возможность использования Open Source, Free, Freeware, ... ПО в конкретной организации определяется ее бизнес-задачами, сложностью ПО, наличием в досточном количестве специалистов и сравнением бюджета внедрения и эксплуатации с аналогичным - для случая платного ПО.

Секция была всьма интересна, так как аудитория была искренне заинтересована в диалоге, а если добавить к этому президента SPB CIO Club Максима Белоусова (а он еще на пленарном заседании - перед круглыми столами произнес зажигательную речь) в качестве модератора, и доклады Геннадия Липича (директор представительства ABBYY в РФ) и представителя Digital Design Рыдлева М. (каюсь - полностью имя не запомнил), каждый из которых излагал свои взгляды на проблему (от "идем серединным путем" - то есть находим баланс между OpenSource и пропиетарным ПО до "только пропиетарное ПО"), то круглый стол удался на 110%. Сужу хотя бы по тому, что времени на обсуждение не хватило. Один из выводов: Open Source для решения бизнес-задач использовать можно, если применить к нему схожий с коммерческим ПО метод оценки: оцениваем риски, сроки, выгоды. И принимаем решение.

Из оставшихся выступлений я на других круглых столах, из того, что успл прослушать, не могу не отметить выступление Вадима Ускова (ООО "Усков и партнеры") - честно говоря, я заслушался. Хотя и смотрел круглый стол по видеотрансляции - была такая "фишка" - плазменные панели и живое видео из небольших залов, где проходили дебаты. Грамотный, и совершенно конкретный докладчик, знающий "свое дело" (защита компаний во время проверок, подготовка к проверкам), плюс ко всему - тонкий дипломат (сужу по тому, как он модерировал). Снимаю шляпу :) (ps - ну не реклама, правда докладчик понравился)...

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

Разумеется, встретил много знакомых :)

PS. Пост получился довольно cумбурным, но зато, как говорится - "по горячим следам" :)

Если Oracle все-таки купит SUN...

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

Я же предлагаю пофантазировать: предположим, покупка одобрена всеми и свершилась. Oracle купил Sun. Что дальше?

Самое важное для Oracle - теперь, благодаря этой покупке, она имеет выход на рынок оборудования, заодно приобретя несколько софтовых проектов Sun - и в первую очередь платформу Java (которую, несмотря на все старания Microsoft, так и не удалось подвинуть никакому .Net).

Что касается цены, то она, скорее всего адекватна - мне почему-то кажется, что в Oracle считать умеют, причем - умеют и просчитывать вперед.
Для меня же в этой сделке интереснее всего будет проследить "софтовый курс" Sun спустя какое-то время после покупки. В частности, интересно, как будет развиваться Java, mySql, и в какую сторону пойдет развитие Open Office, будет ли (и как интенсивно) развиваться и продаваться Star Office.

Что касается "железа", то уверен, что сервера как продавались, так и будут, разве что теперь с предустановленным Oracle, и почти наверняка будут бандлы по принципу "oracle + sun = скидка", наверняка останется в прежнем виде (а, возможно, получит еще один толчок к развитию за счет нового взгляда oracle) Java, а вот насчет всего остального уверенности значительно меньше.

В частности, тот же Open Office. При том, что он есть на компьютере практически любого линуксоида (так как альтернатив, лежащих "на поверхности", просто нет - или они мне не известны), я сильно сомневаюсь, что он (в инкарнации Star Office) приносил Sun'у хорошие барыши. Для меня разработка (вернее, причины разработки) этого продукта - одна сплошная загадка (мнение, что продукт выпускается с целью "подвинуть Microsoft", у меня вызывают сомнения: разработка - штука дорогая, и на "подвижке" ее не отобъешь), при том, что продукт "правильный" и интересный. Хотя бы своей лицензией (хотя и возможностей у него для большинства повседневных операций более чем достаточно).
Что касается mySql, то на первый взгляд все выглядит более радужно: "мускул" официально коммерческий продукт, распространяемый бесплатно в некоммерческих целях. Используется в основном в вебе (и в 95% случаев в бесплатном варианте) - там, где нужно "быстро и просто". Такое позиционирование обеспечит Oracle присутствие в новом сегменте рынка БД (БД oracle для такого рода решений мягко говоря, "тяжеловата" - примерно как из пушки - по воробьям), так что в ближайшее время вряд ли стоит ожидать известий о свертывании разработки mysql.

PS. Все рассуждения, приведенные выше - исключительно мое мнение, не претендующее на истину в последней, предпоследней и вообще какой-либо инстанции. :)

Про видение "заказчик/продавец/исполнитель/пользователь"

Тема стара как мир. И не о кризисе. Местами очень даже теоретическая.

Дано: организация (заказчик ) дозрела до автоматизации. Например, некоторых бизнес-процессов, которые на данный момент не автоматизированы. Вариантов действий в глобальном смысле не так и много:

1. внутренняя формализация задачи - про этот этап вообще-то частенько забывают...
2. определение, "делаем сами" или "покупаем нечто". (Предположим, что "покупаем" - так видится интереснее)
3. мониторинг рынка и определение бюджета
   
4. формирование внятного документа - приглашения на тендер (в нем, по хорошему, должны быть описаны основные моменты: зачем, что, ожидаемый результат и т.д.)
5. рассмотрение предложений (поступают от продавца исполнителя)
   
6. выбор
7. договор
   
8. внедрение (исполнитель)
   
9. эксплуатация (пользователь)
   

П. 7 - 9 пока оставим вне рассмотрения, и перейдем к п.6 - "Рассмотрение предложений" и "Выбор". Проблема в том, что очень часто (статистика взята по 5..10 моим ИТ знакомым из разных сфер основного бизнеса) декларируемые возможности не соответствуют действительности, или соответствуют в некоторых специфических условиях. Решается все, как правило, административными мерами, доработками или патчем, что либо увеличивает бюджет внедрения, либо сроки, либо трудозатраты на баголовство.

Способов борьбы с этим явлением придумано на данный момент два:

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

Как вариант, может "прокатить" комбинация этих двух способов.

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

 А теперь, внимание. Вопрос к коллегам: а как вы решаете подобного рода коллизии? Интересно мнение как "исполнителей", так и "заказчиков".

PS. Очень надеюсь на ответ А.Тенцера, М.Елашкина, А.Куприянова, В.Брокуса, П.Попова и всех-всех-всех (да простят меня не упомянутые лично). :D