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

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

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

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

Получается: "не внедряйте, да не внедряемы будете":)

Оригинал и комментарии: ITBlogs.ru

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

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

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

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

Оригинал и комментарии на ITBlogs.ru

Собеседуя кандидата, натолкнулся на одну любопытную вещь: я просто не понимаю некоторых HR терминов. Например, что такое "активная жизненная позиция"? Или "самореализация"?

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

Например, есть такое красивое почти всем понятное слово - харизма:) Обозначает оно личные качества и особенности, позволяющие ее носителю вести за собой, увлекать и идеалогизировать (слово-то какое!) людей. Интересно, пресловутая активная жизненная позиция - это то же самое? И насколько она важна для соискатиеля на должность программиста? А самореализация? Она нужна кандидату, претендующему на роль технического писателя? Программиста? Менеджера?

Все эти рассуждения я привожу в основном к тому, что достаточно ли определения на собеседовании только профессиональных качеств? Или надо определять и измерять позицию, харизму, самореализацию (плюс еще ряд подобных параметров)?

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

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

Оригинал и комментарии на ITBlogs.ru

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

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

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

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

Оригинал и комментарии на ITBlogs.ru

Навеяло постом Aliona "Из жизни KPI".

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

В каждом регионе таких организаций "всегда есть", покрайней мере можно навскидку назвать две-три, из немаленьких и известных на рынке, которые дают весьма приличный процент соискателей на рынок труда.

Вопрос: зачем оно надо? (Рассматриваем крупные организации,например, ИТ и интеграторов). Не проще ли создавать условия, при которых у 70% ключевых сотрудников не возникнет желания уйти, бросив все?

PS. Очевидно, что серьезные проекты не делаются студентами и новичками. И потеря ключевого или околоключевого человека на проекте может отрицательно сказаться на его сроках и финансовых результатах. Или надежда на другую кузницу кадров?Не понимаю...

Оригинал и комментарии на ITBlogs.ru

Как я и обещал, рассказываю продолжение истории про смену тарифа в МТС.

...

Поездка в контакт-центр ничего не дала: девушка смогла меня убедить, что все будет нормально, надо лишь немного потерпеть. Потерпел. Ничего не произошло, и я отправил в МТС гневное письмо, содержание которого сводилось к тому, что пора бы перевести с тарифа на тариф. И пересчитать стоимость звонков за нехилое время, что МТС спал.

Еще через пару дней мне позвонила из МТС Неизвестная Девушка, которая сообщила о том, что меня наконец-то перевели на интересующий меня тариф. И пересчитали. Правда, один номер из двух:) Со вторым оказалось все не так просто. Когда номер был в корпоративной группе, ему приписали скидку 15% за то, что я буду им пользоваться в течение года.

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

Итого: один телефон переведен (путем ругани и письма, кажется это - единственный способ заставить МТС пошевелиться), по второму - ожидаем:)

О продолжении / завершении этой истории - обязательно сообщу.

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

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

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

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

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

Оригинал и комментарии на ITBlogs.ru