Я выступаю на Russian BI User Group 14го июля 2015
Встреча юзер-группы будет проходить в Microsoft Technology Center 14 июля 2015 года, начало в 17:00. Регистрация обязательна, регистрироваться по ссылке.
Приходите все, будет интересно!
Исследование факторов лидерства в ИТ
Неделю назад я создал опрос, направленный на выявление факторов лидерства http://1drv.ms/1xqh6uX. Получилось всего 261 ответ, что, конечно, мало для полного исследования, но уже достаточно, чтобы выявить некоторые закономерности.
Особенно интересны комментарии участников опроса:
наберите в поиске "лидерские качества", "лидерство". Обладание какими-то супер-знаниями - это последнее, что вы там увидите. Тема лидерства топтана огромным количеством психологов. Наверное было бы интересно опровергнуть их теории, но доказывать их правильность не вижу смысла.
или например такие
Я думаю, что для лидера гораздо важнее другие качества:
Инициативность - он постоянно должен что-то делать, не дожидаясь указания от начальника.
Открытость к людям - стремление помочь им с их проблемами (но без фанатизма).
Харизма - банально, у человека который шумно рассказывает анекдоты, которые поднимают всем настроение больше шансов быть лидером, чем у человека который изучает очередной ЯП за компом и ни с кем не общается.
и даже такие
По сути, это "авторитет". Что бы им стать нужно два фактора:
- Уметь быть убедительным, убеждать. Развитая речь и система аргументации, жизненный опыт (есть что рассказать)
- Поддерживать внутри коллектива справедливость, систему понятий ;-)
В итоге получается человек, с которым комфортно, на которого можно положиться, который никогда не паникует и не теряется. К таким людям внутри коллектива остальные тянутся, вот и получается лидер.
Но это все теоретизирование, а что же нам расскажут результаты опроса?
Инструменты
Я не являюсь профессиональным исследователем и понятия не имею чем отличаются Хи-Квадрат и Критерий Стюдента, а также как считаются доверительные интервалы. Поэтому я взял Excel Data Mining Add-in (https://msdn.microsoft.com/en-us/library/dn282373.aspx). Этот инструмент подключается к SQL Server Analysis Services Multidimensional и использует его механизмы Data Mining для анализа данных в Excel.
Выглядит оно так:
А для анализа таблиц есть готовые инструменты:
Демография
Для начала воспользуюсь инструментом Explore Data, для построения диаграмм
Распределение ответивших на вопрос по должностям:
По возрасту:
По полу:
По стажу на последнем месте:
Получается, что “средний” участник опроса – программист, возраст до 35, мужик, со стажем работы на последнем месте менее 3 лет.
Ключевые факторы
Попробуем сделать анализ.
Воспользуемся инструментом Analyze Key Influencers, чтобы определить какие колонки оказывают наибольшее влияние на те, которые нам надо исследовать.
Основной вопрос был – “Считаете ли вы своего руководителя лидером”, посмотрим что на него влияет.
Analyze Key Influencers использует алгоритм Байеса для выявления связи. Очевидно, что в случае ответа “Готовы ли вы перейти на другую работу вслед за руководителем=Да” отвечающий считает своего руководителя лидером, обратное также верно. Собственно это и был “валидирующий” вопрос в самом опросе.
Второй ключевой фактор – уровень комфорта. Если человек отвечает что ему очень комфортно с руководителем, то с высокой долей вероятности от считает его лидером. Обратное тоже верно, но влияние уже меньше.
Третий ключевой фактор – профессиональные качества руководителя, руководитель с более высокими профессиональными (в той области, которой занимается сотрудник) качествами будет назван лидером чаще, чем руководитель с низкими качествами.
Проанализируем теперь влияние на уровень комфорта, для этого снова запущу Analyze Key Influencers.
Как видим люди чаще оценивают уровень отношений как “Очень комфортно”, когда руководитель дает обратную связь, регулярно общается по неформальным вопросам, принимает инициативы, не критикует и интересуется работой подчиненных.
Также в качестве сильных факторов указано влияние параметров “Готовы ли вы перейти на другую работу вслед за руководителем” и “Считаете ли вы своего руководителя лидером”, так как Байесовый алгоритм не может учесть направление влияния при высокой корреляции между факторами.
Дерево принятия решений
Decision trees прячутся под кнопкой Classify в Ribbon. Но из-за малого объема данных и высокой корреляции между колонками “Готовы ли вы перейти на другую работу вслед за руководителем” , “Считаете ли вы своего руководителя лидером” и “Оцените уровень комфорта в отношениях с руководителем” сходу дерево не строится.
Попробуем немного пошаманить:
- Дискретизирую все текстовые значения, чтобы алгоритмы умели выявлять диапазоны.
- Поправить параметры, которые замедляют “рост” дерева.
Получилась вот такая картинка:
Более насыщенный цвет – больше вероятность, что считают лидером. То есть если вы руководитель и эксперт (в глазах подчиненных), а ваши подчиненные – мужчины, то две трети из них будет считать вас лидером. Иначе вам надо стараться, чтобы подчиненным было комфортно, но в этом случае лишь треть будет считать вас лидером.
Выявление категорий
Воспользуемся инструментом Detect Categories. Он использует алгоритм кластеризации. Я запустил алгоритм на дискретизированных значениях и он выявил у меня 4 категории.
Ниже перечень категорий с наиболее значимыми признаками, названия я сам придумал.
- Молодые ИТшники
- Менее 3 лет на последнем месте работы.
- Не занимают руководящие должности.
- Чаще всех меняли работу.
- Самая многочисленная категория – 129 человек, примерно половина всех опрошенных.
- Старые ИТшники
- Возраст 41-49 лет.
- Стаж – 22-26 лет.
- С текущим руководителем работают от 3,5 до 10 лет.
- Работу давно не меняли.
- Примерно половина из них – руководители (начальники отделов и выше).
- В эту категорию попало 44 опрошенных.
- Терпящие
- Оценивают уровень комфортно как “очень некомфортно” и “местами некомфортно”.
- При этом меньше всех меняли работу и имеют стаж 8-11 лет.
- Руководитель на них “забивает”.
- Часто работают по указке.
- В эту категорию попало - 42 опрошенных.
- “Внимательный руководитель”
- Руководитель знает о планах сотрудника.
- Руководитель дает обратную связь.
- Руководитель – эксперт.
- Руководитель благодарит за достижения.
- Руководитель занимается развитием подчиненных.
- Чаще всего самостоятельно принимают решения.
- В эту группу попало 45 опрошенных.
- В этой группе самое большое число Руководителей Проектов.
А теперь график “Считаете ли вы своего руководителя лидером”
По графику видно, что руководители-лидеры чаще встречаются у старых ИТшников, но это скорее следствие. А вот категория “внимательный руководитель” говорит нам, что тот, кто внимательнее относится к подчиненным скорее будет признан лидером, чем наоборот.
Выводы
Вполне возможно некоторые факторы лидерства остались неучетны в это опросе, но стало вполне ясно, что руководителю в ИТ нужно разбираться в том, что делают подчиненные, позиционировать себя как эксперта в этом вопросе и проявлять внимание к их работе.
Уточню – важно не иметь много знаний\навыков\сертификатов, а быть именно экспертом для подчиненных. Тут много факторов как себя позиционировать, общаться, принимать решения итд.
Я ожидал заметного влияния факторов самостоятельности принятия решений и общения один-на-один, но они почти незаметны.
Ссылка на файл с данными опроса и результатами - http://1drv.ms/1GcAuNj, можете сами провести интересующий вас анализ.
ЗЫ. Несмотря на то, что статья появилась на первое апреля, шуток в ней нет.
Выявление факторов лидерства среди ИТ-специалистов
Буду очень благодарен если вы ответите на небольшой опрос - http://1drv.ms/1xqh6uX.
Опрос полностью анонимный, от вас не потребуется вводить ваши персональные данные, данные о заработной плате и месте работы. Вы можете только оставить email, если захотите получить результаты исследования. Эти email не будут нигде опубликованы и не будут передаваться третьим лицам.
Алиса в стране ИТ-проектов
Про заказчиков
Шляпных дел мастеров я уже видела. Мартовский Заяц, по-моему, куда интереснее. К тому же сейчас май — возможно, он уже немножко пришёл в себя.
— Ничего не поделаешь, — возразил Кот. — Все мы здесь не в своем уме — и ты, и я!
— Откуда вы знаете, что я не в своем уме? — спросила Алиса.
— Конечно, не в своем, — ответил Кот. — Иначе как бы ты здесь оказалась?
Про анализ требований
Не грусти. Рано или поздно все станет понятно, все станет на свои места и выстроится в единую красивую схему, как кружева. Станет понятно, зачем все было нужно, потому что все будет правильно.
Не все ли равно, о чем спрашивать, если ответа все равно не получишь, правда?
— Как мне попасть в дом? – повторила Алиса громче.
— А стоит ли туда попадать? – сказал Лягушонок. – Вот в чем вопрос.
– Ты что, не знаешь, что такое «это»?
– Я прекрасно знаю, что такое «это», когда я его нахожу.
Всё страньше и страньше! Всё чудесатее и чудесатее! Всё любопытственнее и любопытственнее! Всё страннее и страннее! Всё чудесится и чудесится!
Про написание Технического Задания
Я видала такую чепуху, по сравнению с которой эта чепуха — толковый словарь.
Как она ни пыталась, она не могла найти тут ни тени смысла, хотя все слова были ей совершенно понятны.
Если в мире все бессмысленно, — сказала Алиса, — что мешает выдумать какой-нибудь смысл?
Думай о смысле, а слова придут сами.
— Этой ужасной минуты я не забуду никогда в жизни.
— Забудешь, если не запишешь.
Правильность формы несущественна!
Про управление проектом
План, что и говорить, был превосходный: простой и ясный, лучше не придумать. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение.
Любое приключение должно с чего-либо начаться... банально, но даже здесь это правда...
— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно… — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— … только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
Она всегда давала себе хорошие советы, хоть следовала им нечасто.
Не понимаю, как он может когда-нибудь окончить, раз он и не собирается начинать.
Делать ей было совершенно нечего, а сидеть без дела, сами знаете, дело нелегкое.
— С чего начинать, Ваше Величество? — спросил он.
— Начни с начала, — важно ответил Король, — продолжай, пока не дойдешь до конца. Как дойдешь — кончай!
То ли колодец был действительно уж очень глубоким, то ли летела Алиса уж очень не спеша.
Нельзя делать то, что нельзя.
Не понимаю, как он может когда-нибудь окончить, раз он и не собирается начинать.
Про оценку проекта
Алиса засмеялась. «Нет смысла и пытаться, — сказала она, — нельзя верить в небылицы». «Я полагаю, у тебя не слишком много опыта, — сказала Королева. — Когда я была моложе, я имела обыкновение делать это по полчаса в день. Да что там говорить, иногда я успевала поверить не менее чем в шесть небылиц ещё до завтрака».
Пока думаешь, что сказать, — делай реверанс! Это экономит время.
А у нас больше одной пятницы разом не бывает.
Знаешь, сколько стоит его время? Тысяча фунтов одна минута!
Про команду
Чем ниже голова, тем глубже мои мысли.
Лучший способ объяснить – это самому сделать!
Лестные слова часто вынуждают людей действовать.
Про ИТ-индустрию в целом
Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место нужно бежать вдвое быстрее.
Как проектному менеджеру провалить продажу проекта
В статье речь пойдет о типовых ИТшных проектах, которые продают большинство компаний-интераторов\аутсорсеров\разработчиков.
Продажи проектов отличаются от продаж товаров и большинства услуг одним важным свойством – проект нельзя “пощупать” до того, как он реализован в какой-либо мере в силу достаточно большой уникальности. Поэтому большинство тактик, направленных на то, чтобы подсадить покупателя на товар\услугу, а уж потом брать с него деньги, в случае продаж проектов не работают.
Я уже довольно долго занимаюсь продажами ИТ-проектов и часто видел как прекрасно построенные, с точки зрения стратегии, продажи с треском проваливались на пресейле.
Способ №1
Банально затянуть с предоставлением предложения. Казалось бы процесс закупки, особенно в крупных компаниях, может занимать месяцы. Тем не менее люди не любят ждать. Если через неделю после встречи с заказчиком вы не можете предоставить предложение, то вероятность успешного закрытия сделки падает. А если вы тянете месяц, то вероятность становится близкой к нулю.
Происходит такая ситуация очень часто. В некоторых компаниях каждый пресейл это сам по себе проект, который требует много разных специалистов и десятки часов работы каждого. С учетом загрузки людей, перекладывания ответственности друг на друга, процессных барьеров (например кучи согласований) сделать предложение в разумные сроки практически невозможно.
И это при том, что скорость в современном мире – один из важных факторов дифференциации от конкурентов.
Способ №2
Следующий по популярности способ – поздно показывать результат. Типичный план проекта, составляемый ПМами выглядит так:
- Обследование
- Написание ТЗ\Рисование архитектуры\Другие бумажные работы
- Разработка
- Тестирование
- Внедрение и настройка
- Сдача проекта
Получается что заказчик увидит результат только на пятом пункте, при этом пункты 1-4 в совокупности занимают 80% и более затрат. Для оценки проекта такой план может быть и хорош, но для заказчика он явно говорит о том, что заказчик рискует 80% бюджета фактически без возможности что-либо поправить.
При этом большинство ПМов понимают проблему, но даже не пытаются её решать, так как построение плана с итерациями, частичными поставками и ранним внедрением может привести к раздуванию плана.
В одной компании на пресейлах даже прототипы не делают, мотивируя тем, что любое прототипирование - это фиксация некоторых архитектурных решений, которые потом дорого будет исправлять (как архитектору мне такое кажется странным).
Способ №3
Отличный способ провалить продажу проекта – это вываливать на клиента свои проблемы. Чаще всего это проявляется в двух подходах:
- Составляется список ограничений, в которых готов работать исполнитель, которые крайне неудобны заказчику. Например в проектах перехода на новую версию какой-либо системы требуют полную документацию по всем настройкам и кастомизациям, которая отсутствует чуть реже, чем всегда.
- В плане проекта появляются “работы”, которые не имеют фактического результата и служат фактически риск-буферами. Объем этих буферов составляет значительную часть объема проекта.
Все прекрасно понимают, что в проектах есть риски. Если бы рисков не было, то заказчик вполне мог бы и своими силами обойтись. Но любой заказчик прекрасно понимает, что при таких подходах риски пытаются полностью переложить на него, даже если это внутренние проблемы исполнителя.
Первопричина всех проблем
Менеджеров проектов учат, что успех – это попадание в “треугольник” объем-сроки-бюджет. Многие процессы управления проектами рассчитаны на то, чтобы этот треугольник не менял размеры.
На самом деле успех проектов заключается в ценности, которую вы принесли для заказчика и во взаимоотношениях, которые вам удастся построить.
Так как менеджер проектов участвует в процессе продажи практически с самого начала (а иногда и сам выступает в роли продавца), то ему просто необходимо с самого начала настроиться на повышение ценности для заказчика и на выстраивание долгосрочных партнерских отношений.
Постоянно добавляя ценность вы можете маневрировать объемами и сроками проекта, а при хороших взаимоотношениях сможете снять свои риски и получить больше денег. Но для этого надо как минимум в самом начале управлять рисками заказчика в первую очередь, а не применять способы, описанные в этой статье.
