Глупые мысли об IT

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

Может показаться, что я забросил этот блог. Отнюдь :) Просто в данный момент я заканчиваю работу над крупным проектом и все, что я делаю – это  ударными темпами пишу документацию. Писательский зуд удовлетворяется полностью :)
Мой текущий проект является хорошим примером того, что иногда имеет смысл отказаться от тщательного планирования проекта: сформулировать техническое задание, критерии успеха, планировать ресурсы и т.д. Отличительной чертой проекта было то, что бизнес понимал, что “дальше так жить нельзя”. Но, в то же время, никто в бизнесе не обладал полной информацией, как же все-таки они “хотят жить”. Слава Аллаху, эту проблему бизнес так же осознавал. С другой стороны, моя компания, как поставщик IT услуг, обязана была выполнить ряд задач и это было обговорено в контракте. Так к чему это я: нам пришлось отказаться от большинства шагов, присущих хорошему проекту! Все попытки оценить время, требуемое на завершение проекта, ресурсы, создать предварительный детальный технический дизайн упирались в то, что тупо не было возможным получить необходимую информацию от бизнеса. Все, что мы могли сделать вначале – это предоставить приблизительный план действий на две недели вперед. Максимум! Надо отдать должное, бизнес принял данную ситуацию как есть и мы использовали метод “ковбойского наскока”: составили общий дизайн (этакий комьюнике о намерениях), провели небольшой пилотный проект и начали полномасштабное внедрение по типу JFDI (just f…g do it!).
Признаюсь, у меня лично “сердце не лежит” к данному подходу. Но это позволило нам:

• Все-таки начать работу над проектом несмотря ни на что: опасения и недоверие бизнеса (бизнес считал, что мы не справимся с задачей, потому что предыдущий аутсорсер не смог), отсутствие необходимой информации и т.п.;
• Восстановить доверие бизнеса и продемонстрировать, что проект может быть успешно закончен. После того, как мы прошли отметку приблизительно 10% завершенности проекта, бизнес уже не только не вредил, но и начал активно помогать – те люди, которые не имели раньше времени для анализа сложных моментов или обсуждения чего-либо, стали гораздо доступнее для встреч;
• Обычные пользователи, которые участвовали в “пилоте”, почуствовав “вкус новшеств”, помогли нам изменить настроения среди остальных пользователей с пессиместических на более открытые к изменениям;
• Бизнес и мы “наработали” необходимую информацию о структуре бизнеса, требованиях (в плане приложений, доступа к данным и т.п), которая помогла нам во время проекта и поможет нам в дальнейшем.

Самое смешное, что 99% того, чего опасался бизнес до начала работы над проектом, не подтвердилось. Это все было на уровне диалога, который Э.Берн хорошо описал в книге “Игры, в которые играют люди”: вы нас говорите, что вы будете делать, а мы будем придумывать причины, почему это работать не будет. Именно из-за первоначального недоверия и пессимизма мы с большой “пробуксовкой” начали проект.
К сожалению, есть и своя “ложка дёгтя”:

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

Напоследок еще раз подчеркну: если бы мы всего боялись, то ничего бы и не сделали. В некоторых случаях надо плюнуть на все и просто постараться что-то сделать вместо того, чтобы фантазировать на темы “что мы будем делать, если что-то будет не так или не так”. “Глаза бояться, а руки делают” :)

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

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

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

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

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

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

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

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

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

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

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