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

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

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

• Документацию мало кто хочет читать;
• Ее никто не хочет писать;
• В большинстве случаев непонятна полезность уже написанных документов.

Начнем с последнего пункта. Очень часто люди забывают, что документация должна быть применима каким-либо образом в реальной жизни. Если есть много документов, но непонятно, что с ними делать – грош цена всей этой информации. Документация должна быть написана так, чтобы поддерживать ключевые бизнес процессы и удовлетворять потребности в информации людей, участвующих в этих процессах и исполняющих различные роли. 
Простой пример: в моей компании есть четыре основных процесса: “продажа” (“pre-sales”), “инициация проекта”, “выполнение проекта” и “ежедневная поддержка” (“producation/business as usual”). Есть у нас портал, на котором опубликована масса технической информации (есть и неплохие документы). Но: разных людям нужна разная информация на разных этапах. В случае с “продажей” необходимо знать в общих чертах, что мы можем предложить клиенту, какая выгода от этого будет, сколько это будет приблизительно стоить и займет времени. В процессе инициации проекта надо понимать какие есть предварительные требования для внедрения какого-либо решения (инфраструктура, лицензии и т.п.). Во время внедрения – стандартные решения (“best practices”) для технического персонала и стандартный план проекта для менеджера проектов и т.д. Если опубликованные документы не могут моментально “кликнуть” в каком-либо месте, заявляя свою полезность – мало кто будет дотошно разбираться, как можно использовать тот или иной документ. Поэтому вся документация должна быть “привязана” к бизнес процессам, использовать стандартные шаблоны и т.п.
О первом и втором пункте. Все очень просто: люди по своей природе ленивы. Если их не заставлять, то 90% не будут делать “лишних телодвижений”. Для того, чтобы заставить работников писать/читать документацию, оценка эффективности того, как они это делают, должна быть частью ежеквартального/ежегодного пересмотра качества работы (KPIs, “performance review”) этих сотрудников. В таком случае у них будет личная заинтересованность в том, чтобы как можно полнее использовать документацию (т.е. накопленные знания) и самим ее писать (т.е. делиться своими знаниями).

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

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

Может показаться, что я забросил этот блог. Отнюдь :) Просто в данный момент я заканчиваю работу над крупным проектом и все, что я делаю – это  ударными темпами пишу документацию. Писательский зуд удовлетворяется полностью :)
Мой текущий проект является хорошим примером того, что иногда имеет смысл отказаться от тщательного планирования проекта: сформулировать техническое задание, критерии успеха, планировать ресурсы и т.д. Отличительной чертой проекта было то, что бизнес понимал, что “дальше так жить нельзя”. Но, в то же время, никто в бизнесе не обладал полной информацией, как же все-таки они “хотят жить”. Слава Аллаху, эту проблему бизнес так же осознавал. С другой стороны, моя компания, как поставщик 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% случаев замечаний не было, что давало мне основание разослать краткое резюме встречи, включив список людей, кто присутствовал, какие документы рассматривались и что никто не высказал никаких (или дал какие-то комментарии) замечаний.
Иногда замечания были, но не по сути, а чаще всего что какие-то вещи инженера привыкли делать не так. Я думаю, всем понятно, что некоторые вещи можно сделать несколькими способами – все зависит от личных предпочтений. Это были те случаи, когда я “жертвовал малым” – переделывал документы, хотя и мой вариант был верен. Это, собственно говоря, даже не “жертва”, а вполне разумный подход – чтобы не спорить по пустякам.
После такой “массированной артподготовки” практически все документы/идеи проходили на ура. Так что еще раз повторюсь: если хотите что-то сделать и не тратить усилия на ненужные споры – разговаривайте с людьми.

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