Как “продвинуть” свою идею с минимальным сопротивлением

Posted on Friday 17 June 2011 under , by Rustam Sydykov

Привет, народ!

Я начал читать одну интересную книгу: “Психология влияния”. К IT эта книга, собственно говоря, никакого отношения не имеет, но я неожиданно понял, почему в свое время мне удавалось “протаскивать” свои IT дизайны проектов через формальный процесс рассмотрения с минимальной кровью. Раньше я работал на большую компанию, в которой было несколько слабо связанных между собой команд: network, datawarehouse, storage, *unix и т.д. Я был в команде Microsoft (ну, не совсем – просто команда отвечала за wintel платформу :)). Каждый проект следовал стандартному циклу: первоначальное предложение/опции –> дизайн –> внедрение –> передача в production (ежедневная поддержка).  Фаза дизайна включала в себя написание документа для инженеров, как то или иное решение/продукт надо внедрять. Потом системные дизайнеры из разных команд должны были этот документ рассмотреть, высказать свои замечания и если были серъёзные недочеты, документ приходилось переделывать. Очень часто случалось, что недочеты, которые отмечались как “критические”, вызывали бурные обсуждения, споры и доходило чуть ли не до личных обид. В то же время мои дизайны “проскакивали” сравнительно легко.
Читая “Психологию влияния” мне показалось, что я сознательно (и подсознательно в какой-то мере) устранял следующие потенциально неприятные ситуации:

  1. Человеку очень трудно изменить свое мнение, которое он высказал публично. В данном контексте “публично” я подразумеваю во время встреч, на которых обсуждались документы IT дизайнов;
  2. По моему, я уже про это писал, но каждая идея проходит через фазы: “Это полное гавно”, “Что-то в этом есть” и “Отличная идея, я всегда так говорил!” :). Подвидом этого варинта является “Твоя мысль правильная, но то что я говорю – правильнее”.

Кроме того, каждый раз получалось так, что я косвенно вовлекал своих коллег в процесс формирования идеи дизайна какого-либо решения. В результате, сказав “да” один раз (неформально одобрив идею), они уже не имели морального обоснования яростно говорить “нет”.
Что я делал: да ничего особенного! Никаких манипулятивных приёмов или “расставления логических ловушек”. Коротко методику можно выразить так: разговаривайте с людьми!

  1. Спрашивайте совета или неформального подтверждения правильности вашей идеи/мысли/подхода на ранних стадиях проектов: перед тем как что-либо оформлять документально, я обходил всех коллег, которые будут вовлечены в рассмотрение дизайна и его внедрение. Я прекрасно знаю, что не могу всего знать и что-либо мог сделать неправильно. Со своей глупостью лучше столкнуться в начале, чем в конце;
  2. Постарайтесь ознакомить людей с вашей идеей как можно на более раней стадии. В крайнем случае, вы пройдете через первую фазу – “это полное гавно” быстрее. В лучшем варианте – ваша идея не вызовет мгновенного отторжения, так как ее можно представить как не окончательный, “окостеневший” вариант, а больше как “документ о намерениях”. Кроме того, если будут возражения к вашей идеи, они будут сделаны не публично, не в письменной форме и вам потом будет легче убедить людей поменять их точку зрения;
  3. Получите неформальное подтверждение правильности ваших идей. Желательно письменно :). Нет, я не призываю никого заставлять расписываться кровью на пергаментах, достаточно будет даже короткого е-мейла от всех вовлеченных в обсуждение :)
  4. Будьте готовы пожертвовать “малым” ради “большого”. Если есть разногласия в несущественных вопросах, лучше уступить, чем “бодаться” и испортить себе нервы.

Вот и все. Что я делал: каждый раз кратко обговаривал и советовался со своими инженерами и коллегами о любых предстоящих проектах выше определенного порога сложности. Людей по пустякам не дергал, но если чуствовал, что обсуждение может перерасти в “свалку” – обязательно лично обходил всех влиятельных лиц :) Особенно, не дай бог, дело касалось о внедрении систем, которые занимались проводкой денежных транзакций, обработки данных о клиентах и т.п. Я подходил к архитекторам отдела информационной безопаснсти и заранее, до начала проекта просил объяснить мне, на какие моменты мне надо будет обратить внимание. Во первых, люди понимали, что я уважаю их и их мнение; во вторых, часто действительно они давали мне дельные советы в области информационной безпопасности. Столько есть законов и подзаконных актов, регулирующих сохранность данных, что я диву давался. К примеру, если какая-то часть сервисов обслуживания клиентов отдана на откуп аутсорсеру, находящимся за пределами Евросоюза, то надо быть способным показать, что данные о клиентах или платежах не могут быть перемещены за пределы Евросоюза. Речь идет о массовом экспорте данных – списывание ручкой с экрана информации о клиенте в расчет не принимается. Это по п.1 и частично по п.2
Дальше по п.2: я не стеснялся рассылать почти законченные документы, формулирующую идею или дизайн до того, как отправлять их на формальное рассмотрение. В общем случае смысл идеи был уже “переварен”, принят и тогда детали будут так же приняты благосклонно. Могут возникнуть вопросы, но критических замечаний, я думаю, удасться избежать.
Обязательно просите послать короткий е-мейл, что документ рассмотрен и особых замечаний нет. Как раз в книге “Психология влияния” я прочитал подтверждение этой мысли: если человек что-то написал, то он будет стараться придерживаться этого. Естественно, не все предоставляли мне отзывы. Но я еженедельно проводил встречи с инженерами, на которых снова коротко рассказывал о том, что я “надумал” и спрашивал, есть ли замечания. В 99.99% случаев замечаний не было, что давало мне основание разослать краткое резюме встречи, включив список людей, кто присутствовал, какие документы рассматривались и что никто не высказал никаких (или дал какие-то комментарии) замечаний.
Иногда замечания были, но не по сути, а чаще всего что какие-то вещи инженера привыкли делать не так. Я думаю, всем понятно, что некоторые вещи можно сделать несколькими способами – все зависит от личных предпочтений. Это были те случаи, когда я “жертвовал малым” – переделывал документы, хотя и мой вариант был верен. Это, собственно говоря, даже не “жертва”, а вполне разумный подход – чтобы не спорить по пустякам.
После такой “массированной артподготовки” практически все документы/идеи проходили на ура. Так что еще раз повторюсь: если хотите что-то сделать и не тратить усилия на ненужные споры – разговаривайте с людьми.

Засим раскланиваюсь,
Рустам.

“Провал” IT проекта с точки зрения бизнеса

Posted on Wednesday 8 June 2011 under by Rustam Sydykov

Привет, народ!

Что-то меня в последнее время потянуло в “негатив” :) Рассказываю о проблемах в работе вместо того, чтобы делиться умными мыслями (трудно делиться  тем, чего нет :)). Просто я нахожусь в процессе миграции учетных записей пользователей в AD в новый дизайн и проблем у меня хватает :)
Как мне кажется, любой IT проект может быть воспринят бизнесом как “провальный” или “не оправдавший надежд”. Все зависит от того, насколько видны конечным пользователям изменения в положительную сторону в их работе. Часто бывает, что все изменения произошли где-то на заднем плане, а вот пользователям вроде бы ничего и не перепало. Или проект обещал произвести “революцию”, а закончилось все “эволюцией”. Я уже раз упомянул про “ожидания пользователей”. Очень важно быть предельно открытым в плане того, какую выгоду бизнес будет иметь от изменений. Если не-IT людям наговорили “с три короба”, лишь бы добиться финансирования проекта, скорее всего потом прийдется долго и упорно краснеть за свои слова. И потом, когда действительно подойдет время чего-то глобального, желания бизнеса инвестировать деньги/ресурсы в этот проект может и не быть.
И еще одно: нежелание самого бизнеса меняться. Это может быть как отказ изменить что либо в бизнес-процессах, так и нежелание конечных пользователей делать что-то по другому. Типа: “Мы всегда чесали левое ухо правой ногой и хотим продолжать это делать. Во первых: не сомневайтесь, что нам это надо! Во вторых: предложенная вами идея внедрить ваш замечательный чесатель-заменитель правой ноги нам совершенно не подходит!”.
В одном случае это может быть просто привычкой С этим бороться просто: можно просто сделать необходимые изменения и люди быстро привыкнут. Это людская натура: не любить изменения :) Я так сделал в текущем проекте: пользователи кричали, что для них нет более приятной вещи, чем получать доступ к сетевым ресурам по UNC или подключая десяток сетевых дисков. Тупо-молча им подключили один сетевой диск с консолидированными сетевыми папками через DFS. Сначала были жалобы по поводу структуры папок, но я был готов “слить” эту проблему, так как надо же было им в чем-то уступить :) Сейчас они уже забыли, как лазили по разным файл серверам в поисках своих папок и все делают через DFS.
Есть еще и второй вариант: пользователи сабботируют изменения по каким-то непонятным причинам. Просто “не нравится и все!”. Может, они боятся, что после внедрения новой системы их сократят (актуально было для Украины), а может, просто какие-то “подковерные” игры. Здесь ничего не поможет, кроме как четкое и однозначное указание вышестоящего лица. Этих “вышестоящих лиц” надо искать либо среди тех, кто выступает заказчиком (“stakeholders”), либо непосредственно среди  ответственных за проект сотрудников в бизнесе (“accountable”).
Надеюсь, от этого поста будет хоть какая-то вам польза и я не зря потратил 20 минут в поезде, набивая этот текст.

Засим раскланиваюсь,
Рустам.

Делегирование обязанностей

Posted on Thursday 2 June 2011 under by Rustam Sydykov

Привет, народ!

Постоянно себе твержу: не надо стараться “залезть во все дыры”, не надо стараться делать все самому! Не получается :)  Очень трудно избавиться от привычки что-то делать самому, особенно если знаешь, что сам сделаешь лучше, чем кто-то другой. В текущем проекте я взялся временно работать как инженер, так как мой инженер “застрял” в Индии из-за проблем с визами. Мне пришлось и мигрировать пользователей, и разбираться с их проблемами. С одной стороны, когда непосредственно контактируешь с обычными пользователями – это самое большое удовольствие! Решаешь проблему, люди искренне благодарны. Особенно, если они сразу видят улучшения или удобства в своей работе. Правда, иногда кажется, что люди “роют” и-нет в поисках каких-либо заковыристых проблем, “ломают” свой компьютер и звонят тебе, чтобы ты помучился. Одних проблем с Outlook-ом я столько нагляделся, что даже не знал, что в такой относительно простой программе можно столько натворить. В общем, бизнес сейчас доволен, так как я могу быстро и легко решить 99.9999% их проблем. Но: теперь мое непосредственное участие поставлено бизнесом как обязательное условие для продолжение проекта! Я уже не могу так легко “спрыгнуть”, пусть даже этот случай и обговаривался с бизнесом. Кроме того, мою работу тоже никто не отменял, мне приходиться и заниматься мелкими техническими проблемами, и продумывать дальнейший дизайн и начинать писать документацию. А эти действия слабо совместимы друг с другом. Я лично не могу постоянно отвлекаться на звонки и е-мейлы и в то же время делать что-то глобальное.
Так что мой совет: если по роду деятельности вам не положено чем-либо заниматься – не беритесь! Если есть ответственный человек для этого – он и должен это делать. Максимум – можно обещать ему помощь и “наставлять на путь истинный” :) Держитесь в рамках своих должностных полномочий – это хорошо и вам, и делу.

Засим раскланиваюсь,
Рустам.