Работаем с заказчиком в условиях форс-мажора


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

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

Речь пойдет о разработчиках программного обеспечения. А именно, об особенности коммуникации с иностранными заказчиками в условиях "революции". Как показали события 2004 года, заказчики могут быть заметно обеспокоенными революционными событиями. Я как раз имел опыт общения с американскими заказчиками в "революционные" дни.

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

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

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

В моем случае от заказчика я получил такое сообщение:

 интересный блог [ссылка] с киевского "фронта"  interesting blog from the "front lines" of kiev

Это частный блог. Автор блога, похоже, американец, был на Майдане во время "революции". И выкладывал новости с "линии фронта", прямо с Майдана, с палаточных городков. Кроме своих сводок автор выкладывал информацию, подготовленную жителями палаточных городка, были сообщения от разных общественных организаций. Есть информация с других частных блогов на тему "оранжевой революции", авторами которых были добровольцы Корпуса Мира (Peace Corps volunteers).

На первый взгляд, блог был интересный, и, в основном, отражал мирный характер акций. Тем не менее, на блоге встречались слова: убийство (a murder), химическая атака (acid attacks), акты насилия или обмана (acts of fraud or violence).

Естественно, что такие детали звучали тревожно для заказчиков. Хоть и не было вопросов типа "У вас действительно творится насилие?", именно эти слова (убийство, химическая атака, акты насилия или обмана) необходимо было сразу прокомментировать и опровергнуть.

Для того, чтобы общий тон ответа заказчику не сильно отличался от официальных новостей, что могло бы породить много вопросов и подозрений, свой ответ я сопоставлял с новостями от CNN. Сложно сказать, что новости на CNN были прямо с линии фронта, но подача информации была достаточно объективной и адекватной, а доверие у американцев (да и во всем мире) к CNN высокое.
Вот какой ответ у меня в итоге получился:

Я прочитал блог, о котором вы говорили. Для меня странно слышать новости о насилии и российских войсках в Киеве. Лично я не видел никакого насилия. Местные СМИ также не сообщали о таковых. В центре города происходят достаточно мирные демонстрации. Другая же часть Киева, также как и наша компания, продолжит жить как обычно.   Well… I've read the blog you sent me.
I am confused with the news about violence and Russian troops in Kiev. I personally did not see any violence, nor local mass media reported any. Fairly peaceful demonstrations happen downtown, rest of the city continues living in usual pace, so does our company.

Более того, через несколько дней автор блога (о котором говорил заказчик) опроверг информацию про насилие. Я, в свою очередь, немедленно сообщил об этом заказчику, дабы ему стало еще спокойней:

Если вы посмотрите на БЛОГ, вы увидите, что автор блога забрал обратно свои слова о насилии в Киеве: "Несколько исправлений… Во-первых, информация от 24 числа о столкновении милиции и демонстрантов является неточной. Оказывается, там просто были некоторая толкучка и кто-то перестараться в лозунгах. Извините."

 "A couple of corrections. . . First, the report of 24 Nov that the militia was clashing with protesters was inaccurate. It seems now that there was some pushing and shoving, and someone overreacted with their reporting. I apologize for that."

Вот еще несколько примеров дискуссии с заказчиком про "оранжевую революцию".

ЗАКАЗЧИК: Только вот прочитал новости из Киева. Захватывающие времена!
РП (РУКОВОДИТЕЛЬ ПРОЕКТА): Да!
ЗАКАЗЧИК: Пугающие времена?
РП: Не такие уж и пугающие
РП: Верю, что все будет нормально.
ЗАКАЗЧИК: Ваши новости на первых полосах тут  

ЗАКАЗЧИК: Как дела в Киеве? Чем все закончится по твоему мнению?
РП: Пока все нормально. Насилия на улицах Киева нет. Мы работаем как обычно.
ЗАКАЗЧИК: Разделение [страны]?
ЗАКАЗЧИК: Новые выборы?
РП : Верховный суд сейчас рассматривает дело о результатах второго тура выборов. Касательно разделения… Сложно судить на данный момент, но я лично не думаю, что произойдет разделение. Посмотрим.

ЗАКАЗЧИК: Just read the news about Kiev. Exciting times!
РП (РУКОВОДИТЕЛЬ ПРОЕКТА): Yes!
ЗАКАЗЧИК: Scary times?
РП : Not so scary actually
РП : I believe all will be fine.
ЗАКАЗЧИК: It's made front page of all the papers here.  

ЗАКАЗЧИК: How are things in Kiev? What do you think will be the outcome?
РП : So far so good. No violence on Kiev streets, we are working at our usual pace.
ЗАКАЗЧИК: Partition?
ЗАКАЗЧИК: New elections?
РП : Supreme Court reviews election case this minutes. As for partition… difficult to judge at this point, but I, personally, don't think that partition will happen. We'll see.

Если обобщить информацию, то вот какими принципами и правилами я пользовался при общении с заказчиком во время "революции":

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

— Избегал слова "революция". И не поощрял заказчика в использовании этого слова. Для американцев "революция" может означать 1917 год. А это уже страшно… В действительности, то, что происходило — это мирные демонстрации против фальсификаций.

— В своих ответах опирался на факты. Надо было быть осторожным со своими заключениями, выводами, прогнозами. Личное мнение это хорошо, но не к месту в том случае. Я мог чего-то не знать, что-то не так понимать, в конце концов, мое мнение могло отличаться от мнения заказчика, что тоже могло быть не очень хорошо. В результате мое видение могло отличаться от официальной (CNN) информации. Поэтому…

— Я сверял концепцию своих ответов заказчику с авторитетными (для заказчика) СМИ. Если бы мой меседж концептуально отличался от авторитетных новостей, это вряд ли успокоило заказчика. И даже наоборот.

Тезисы, которые надо было донести заказчику:

— Демонстрации за честные выборы исключительно мирные.

— Остальная часть города живет своей жизни, равно как и наша компания.

— Цель демонстраций — разрешить фальсификации мирным путем.

— Главные ожидания демонстрантов — это поворот Украины в сторону настоящей демократии.

— Команда работает как обычно, а события существенно не влияют на ее производительность.

— Большинство украинцев, похоже, готово принять результаты честных выборов, не зависимо от того, кто будет президентом.

Типичные вопросы и ответы:

Q: Надеюсь, что результаты выборов не повлияют на вашу повседневную жизнь. [имеется ввиду не вообще, а конкретно тогда, когда страсти накалились]
A: Пока что все происходит мирно. Люди демонстрируют свою волю к демократии. Думаю, что только недавно многие начали понимать, что их голоса имеют значение.

Q: Как дела в Киеве?
A: Если вкратце, то народ положительно возбужден. Все события происходят в центре Киева, однако остальная часть Киева и Украины, как и наша компания, живет своей обычной размеренной жизнью.

Q: Надеюсь, до агрессии не дойдет.
A: Пока что ситуация захватывающая. Я не увидел признаков агрессии. 

Q: Мы ту по ТВ смотрим события из Киева и думаем о вас, ребята.
A: Спасибо! Надеюсь, мы идем к настоящей демократии. И это вдохновляет. 

Q: Hope that the results of the elections in Ukraine do not affect your daily life…
A: Well, it has been rather peaceful. People are showing there vote for democracy. I think only recently many started to understand that their single vote can make a difference.

Q: How are things in Kiev?
A: Well, in brief, it's excitement in the air. Though, all events are happening in the downtown, while the rest of Kiev and Ukraine keeps working in usual pace, so does our company.

Q: I hope it won't get aggressive.
A: It has been rather exciting and encouraging. I did not notice any sign of aggression so far.

Q: We have been watching Kiev events on TV and thinking of you guys.
A: Thanks! I hope we are heading to the country of the true democracy. And it encourages me very much.

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

Самое главное в таких условиях — это успокоить заказчика. При этом нужно понимать, что заказ может воспринимать ситуацию не так как вы, заказчик может драматизировать. Нужно, отнестись внимательно к опасениям заказчика и деликатно опровергнуть или смягчить опасения. Хорошо, если вы обладаете информацией о форс-мажоре и достаточно точно можете прогнозировать ситуация. И если вы уверены что все будет ОК, тогда вам проще всего успокоить заказчика. Ну а если все плохо, то вам в первую очередь нужно минимизировать удар от форс-мажорной ситуации. Но об этом как-нибудь потом.

Украинцы держат на руках 40-60 млрд долларов

Украинцы держат от 40 до 60 млрд долл наличными и не отдают их в банки, сообщил президент Ассоциации украинских банков (АУБ) Александр Сугоняко.
Если эти деньги вернуть в банковскую систему, не будет необходимости просить у МВФ очередной транш кредита.

По его словам, основная проблема украинской экономики заключается в отсутствии доверия населения к банкам. "Проблема кризиса в банковской системе не в том, что не хватает денег, их достаточно", — убежден Сугоняко. Поэтому первоочередным заданием для власти он называет возвращение доверия людей к банкам.

Напомним, по информации АУБ, в январе этого года украинцы забрали из банков 21 млрд долларов.

По материалам РБК-Украина

http://korrespondent.net/business/economics/787618/ 

Планируем отпуск на проекте


Многим из Вас, как руководителям проектов, приходилось, или придется, подписывать заявление члена команды на отпуск. Перед тем как отпустить человека в отпуск необходимо оценить последствия отсутствия члена команды и предпринять меры для минимизации риска опаздывания проекта. Об этом и пойдет речь.

Вам необходимо правильно планировать отпуска в команде, дабы избежать недоработки запланированных часов, или же выхода за рамки графика проекта, так как с одной стороны, все члены команды имеют право на 24 календарных дня отпуска (плюс праздники), а с другой стороны, сотрудник должен отработать запланированные часы, и что особенно важно — часы предоплаченные заказчиком.

В зависимости от специфики производства и особенностей контракта с заказчиком, решения могут быть разными.

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

Что делать, если Вы производите программы в качестве субподрядчиков или аутсорсинговой компании, причем ваш заказчик не оплачивает отпуска разработчиков, а оплачивает конкретный час работы программиста? Ведь конкретный предоплаченный час работы надо отработать, с одной стороны, а с другой стороны, Вы естественно не можете отказать программисту в законном отпуске. К тому же важно с политической точки зрения не дергать заказчика с неожиданными сюрпризами про отпуск и про то, что какая-то работа не будет выполнена в срок. В данном вопросе нет универсальных рецептов, и конкретное решение будет зависеть от конкретной ситуации. Однако вот несколько типичных приемов и правил, которым можно следовать.

Планируйте отпуска команды наперед. До начала проекта или до начала сезона отпусков, который начинается в мае-июне и заканчивается в сентябре-октябре, попросите всех членов команды прикинуть, когда они идут в отпуск. Причем попросите делать это сообща, чтоб не получилось, что полкоманды идет в отпуск одновременно. Объясните команде важность равномерного движения проекта и соответственно равномерного распределения отпусков. Сведите все даты отпусков в MS Project, FastTracker или другую программу для планирования. Сделайте этот документ доступным всем членам команды, чтоб каждый мог знать даты отпусков своих коллег. Если возникают конфликты между отпусками, обсудите с командой, попросите передвинуть. Практика показывает, что во многих случаях отпуска получается утрясти.

Если не получается урегулировать конфликты отпусков, то хотя бы убедитесь, что в отпуск не уходят достаточно много членов команды, чтобы существенно замедлить работу, что, в свою очередь, может заметить заказчик. Особенно, это важно когда в отпуск идут ключевые игроки команды.

Постарайтесь спланировать отпуска так, чтоб во время выпуска продукта (или других важных вех) вся команда была на месте.

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

Когда член команды уходит в отпуск, убедитесь, что его/ее часть работы передана другому члену команду. Ясное дело, человек не может делать двойную работу — "за себя и за того парня" — в течение 8 часов рабочего дня. Если есть возможность платить сверхурочные, и инженер согласен работать больше, то проблема решена. В противном случае, имея человека на подстраховке, вы как минимум будете уверены, что в случае срочности — скажем нужно срочно исправить ошибку в области, которой занимается программист, ушедший в отпуск — задача будет выполнена.

Вы можете назначить дополнительного инженера вместо инженера, ушедшего в отпуск. Однако такое решение имеет смысл, если нужно выполнять рутинные задачи, не требующие значительного предварительного обучения. Или же, если задачи сложные, убедитесь, что какое-то время до начала отпуска оба программиста отработают вместе. Т.е., фактически, подменяющий программист проработает больше, чем Ваш постоянный программист будет в отпуске. Это необходимо сделать, дабы нивелировать период обучения и выход подменяющего программиста на "мощность" отпускного программиста. В результате временный программист выполнит необходимый объем работ (но за большее время) и проект будет идти по графику.

Если же проект или задача программиста краткосрочна (скажем, меньше года), то вы можете попросить перенести отпуска. Вам, возможно, придется проявить Ваши таланты и способности менеджера и уговорить программиста уйти в отпуск позже (или раньше) проекта. К чему апеллировать зависит от конкретного человека и ситуации. Кому-то достаточно будет рассказать о критичности и важности выполненной вовремя задачи для успешной сдачи проекта. Другому — пообещать и обеспечить более длительный отпуск после сдачи проекта. А кто-то даже согласится поработать сверхурочно, чтобы выполнить работу раньше и компенсировать переработку отпуском.

Что, если на Вашем проекте есть уникальные программисты? Пытайтесь избегать подобных случаев. Иногда это сложно (или дорого), а иногда нереально в ограниченные сроки. Например, уникальными инженерами для проекта могут считаться математические/статистические программисты, специалисты по специфическим технологиям и языкам программирования. Приглашать на замену других узконаправленных специалистов на 2-3 недели, как правило, никто не будет, так как это может быть дорого или не реально в принципе (отдел кадров просто не сможет найти такого специалиста в ограниченные сроки). Это один из случаев, когда Вам придется согласовывать отпуск программиста с заказчиком. Вероятно, Вам придется компенсировать заказчику время отсутствия такого программиста (или программисту придется перенести свой отпуск).

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

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

Для покрытия недоработок по причине неожиданного отсутствия членов команды, вам, возможно, понадобится иметь резерв запланированных переработок. Такой резерв может формироваться из-за разницы между фактическими часами работы и часами оплачиваемыми заказчиком. Или же иметь на проекте дополнительного человека — сверх того что оплачено заказчиком.

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

Если человеку неожиданно нужно отсутствовать день-два, то вы можете договориться покрыть недоработанные дни отпуском или отработать часы в другие дни.

В некоторый случаях, если инженер запланирован на год и более, то Вы можете отпускать его/ее в отпуск без замены, сверхурочных работ и даже согласования с заказчиком. На длительных проектах — более года — человеко-часы оплаченные заказчиком частично покроют отпуска если:
— заказчик оплачивает как минимум 160 часов за инженера в месяц — это 1920 часов в год
— фактические часы на вашем проекте составляют не менее 40 часов в неделю. В год это более 1920. Например, в 2008 — это 2011 часов в год.

Таким образом, например, на 2008 получается такой расчет:

2011 Фактические рабочие часы на вашем проекте в 2008 году
1920 Рабочие часы оплаченные заказчиком (12 месяцев х 160 часов в месяц)

91 час на покрытие отпусков, а это около 2,3 календарных недель отпуска
===
Т.е. вам не нужно будет покрывать заменами или сверхурочными 2.3 недели отпуска инженера. Это время (2.3 недели) оплачено заказчиком. При этом остальное время отпуска приходится оплачивать компании за свой счет, и, следовательно, нет необходимости согласовывать и даже ставить в известность заказчика (конечно, если речь не идет о сдаче проекта или другом важном событии).

Я считаю, что на длительных проектах оплата заказчиком отпуска инженера — это вполне нормальным явлением, равно как вполне естественно, что программист имеет законное право на 24 календарных оплачиваемого отпуска. Особенно если заказчик оплачивает конкретного человека. Если же заказчик не понимает этого, то политика по отпускам может быть приблизительно такой: "Если Вы хотите, чтоб работа не прекращалась во время отпуска программиста, нам необходимо будет привлечь других программистов на замену. Это в свою очередь может замедлить работу, так как 1) необходимо будет вводить нового человека в курс дела, 2) разбираться в чужом коде сложнее, чем создавать с нуля или разбираться в своем коде".

 

Это позор

Недавно компания Apple провела презентацию новой версии операционной системы iPhone OS 3.0. Представитель компании начал презентацию с демонстрации карты, на которой была продемонстрирована официальная распространенность iPhone в мире — т.е. куда официально Apple поставляет телефоны. Так вот Украина наряду с Боливией, Беларусью, Ираком, Ираном, Афганистаном, Монголией не имеет официальных поставок iPhone. Даже в Саудовской Аравии, Мали, Сенегале есть официальные поставки iPhone. Красным на карте отмечены страны, куда Эпл официально поставляет iPhone.

Спецификация — это просто!


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

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

Параметр Значение
Дата 4 ноября, 2004
Идентификатор 5
Цвет Красный
   
   

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

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

— дважды щелкаешь на ячейку,
— появляется диалоговое окно,
— в этом окне два поля ввода, где ты набираешь значения,
— нажимаешь на ОК в окне,
— в результате значения отображаются в таблице.

Чтобы отредактировать таблицу, также надо было дважды кликнуть на ячейку и изменить значение в отдельном диалоге редактирования.

Я же в свою очередь не согласовал метод ввода данных в таблицу с заказчиком. Таким образом, мы, как разработчики, были виноватыми. Нам тогда даже пришлось вернуть заказчику где-то 1.5 ч-м (в деньгах).

После этого случая мы приняли решение обговаривать с заказчиком каждую деталь новой функциональности. Очевидно! Если что-то не ясно, плохо прописано, не прописано вообще, мы не догадывались, а согласовывали с заказчиком в духе "Мы предлагаем АБЦ. Согласен?" или "Вот тут не совсем ясно. Ты имел ввиду АБЦ?". Подобные коммуникации происходили неформальным образом (не в официальном документе, спецификации), т.е. каждая проблема отдельно, в отдельном сообщении. Часто высылали демонстрационные версии продукта, чтобы заказчик мог вовремя показать, что не правильно с его точки зрения. В общем, все стало на свою колею, и мы успешно выпустили ту версию продукта.

Со следующей версией того же продукта мы пошли дальше. Мы решили формализовать процесс работы со спецификацией. Теперь мы прописывали все детали функциональности в отдельном документе — функциональной спецификации.

Об этом и пойдет речь.

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

Информации, всяческих рекомендация и стандартов о том, как правильно составлять спецификации — много. Очень часто встречаются «фундаментальные труды» по спецификациям, в которых охватывается все (ну, почти все), со сложной структурой, всеми возможными нюансами и деталями. Спецификации, в итоге, могут разрастись в несколько толстых томов. Возможно, это все нужно на сложных и трудоемких проектах или для сложной и емкой функциональности программы.

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

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

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

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

А когда вы начнете писать спецификации, работа пойдет сама по себе, — главное начать.

Я лично при написании функциональной спецификации пользуюсь несколькими простыми принципами: 1) простота изложения, 2) лаконичность, 3) полнота, 4) самодостаточность документа.

1) Простота. Ни для кого не секрет, что заказчики, как правило — занятые люди. И это не должно являться оправданием тому, что заказчик не отвечает на вопросы и не утверждает спецификации. Это реальность, с которой надо жить и под нее подстраиваться. Таким образом, спецификация должна быть простой. А именно:

— должна быть написана простым человеческим языком, не нужно формулировок в духе "согласно принципу банальной эрудиции каждый индивид…"

— не иметь сложную структуру,

— по возможности, спецификацию нужно делать, чем меньше, тем лучше.

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

2) Лаконичность. "Вода" в спецификации не нужна. Также не нужны в спецификации размышления. Нужны только выводы и руководство к действиям.

Плохо: "Вероятней всего, пользователь не захочет печатать XY графики, так как эти графики низкого качества и бесполезные. Поэтому мы не будем позволять пользователю печатать XY графики и деактивируем команду Печать."

Лучше: "Команда Печать будет неактивна для XY графиков."

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

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

Не надо писать о стандартном поведении программы. Например, не надо указывать, что выпадающий список будет содержать 5-12 элементов. Это стандарт, прописанный в руководстве по пользовательскому интерфейсу.

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

4) Самодостаточность. Спецификация, как единый документ, должна быть самодостаточна. Не стоит наполнять документ ссылками. Пользователь документа не должен лезть в какие-то другие источники, чтобы получить полное представление о том, как должна работать "фишка". Надо упростить работу с самим документом.

Вот каким простым шаблоном я пользуюсь:

Функциональная спецификация
[название функциональности, функции]
[дата создания]
[дата модификации]
История изменения:
[дата] [Имя] [краткое описание изменений и дополнений. Пример: Добавлена поддержка NTSC в разделе "Форматы"]

Запрос заказчика
Тут вы копируете текст заказчика "буква в букву". Этот текст является частью спецификации. Это базовое видение заказчиком функциональности, которое вами потом детализируется, уточняется, дополняется в следующих разделах спецификации. При этом ни одно предложение заказчика не игнорируется.

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

Примеры:
— Библиотека (.dll) для экспортирования графических файлов.
— MSXML для экспорта и импорта файлов формата XML.
— Internet Explorer 5 для правильной адресовки панели инструментов.
— Quick Time для Windows для проигрывания видео.

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

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

— команды меню
— кнопки на панели инструментов
— диалоговые окна
— новые элементы в существующих диалогах
— элементы документа программы, и т.д.

Очень хорошая идея здесь — показать эскизы. Эскизы очень упрощают восприятие информации.

Так же в этом разделе вы должны указать поведение программы, взаимодействие элементов интерфейса, значения по умолчанию.

Пример: "Кнопка "Плот" будет доступна только в том случает, если вы выбираете 2 или три сегмента в списке "Сегменты".

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

— перечисляете тексты сообщении об ошибках для каждой противоречивой ситуации

— перечисляете проблемы, которые вы будете просто игнорировать (если вероятность и эффект проблемы очень малы, а решить проблему очень сложно)

— автоматическое исправление ошибки без сообщения об ошибке. Пример: "Если уравнение полностью не описано в диалоге "Определение Уравнения", то остальные элементы диалога остаются неактивными."

Оценки
Здесь вы указываете оценки на:
— программирование
— тестирование
— дизайн
— функции.

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

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

Ниже я привожу примеры реальных спецификаций, которые успешно работали.

***

SPECIFICATION
===========
Date: May 21, 2001
Feature: Plotting single value

A. INTERFACE

1. Look of the "Range and tick interval" group when user wants to plot a single X {Y} value:

———-Range and Tick Interval————-
Plot: [Single X {Y} value]
Value: [input field]
Label: [input field]
—————————————————

2. Look of the "Range and Tick Interval" group when user wants to plot a range of X {Y} values:

———-Range and Tick Interval————-
Plot: [Range of X {Y} values]
Minimum: [input field]
Maximum: [input field]
Interval: [input field]
Starting at: [input field]
—————————————————-

B. BEHAVIOR

* Plot is dropdown with two choices: "Single X {Y} value" and "Range of X {Y} values". "Plot: [Range of X {Y} values]" is default.

* The "Plot" dropdown will be available only when two or three segments are chosen in the "Gaps and Direction" dropdown and only for one segment. So that if user defined "Single X {Y} value" for one segment, on the rest segments the "Plot" dropdown will be grayed out with "Range of X {Y} values" selected.

* "Value: [input field]" will contain by default: minimum X{Y} for the first segment and maximum for the last segment. This input field will be grayed out (with default value inside) for the first and the last segments. For the middle segment (in case of 3 segments) the "Value" field will be enabled, so that user can enter the value, the default in this case will be the median of X range.

* "Label: [input field]" will contain by default: minimum X{Y} for the first segment and maximum for the last segment. This input field will be always enabled.

* Behavior and defaults of "Minimum:", "Maximum:", "Interval:", "Starting at:" when "Plot: [Range of X {Y} values]" is selected we leave the same as in program 1.

* In case user opens old file, program will set the "Plot" dropdown to default value — "Range of X {Y} values".

C. IMPLICATIONS AND OTHER COMMENTS

This feature will not change file format.

D. EVALUATION

N days

***

SPECIFICATION
===========
Date: February 15, 2001

B. ERROR TRAPPING

— If equation is not completely described in the "Equation Definition" tab, disable all controls for "Initial Values" and "Constraints".

— Check constraints violation only if user chooses from the dropdown in the "Initial Values" tab. Don't let user leave dialog with constraints' violation of initial values.

— In case of inconsistent constraints, clear the checkboxes in the bottom group of constraints starting from the lowest.

C. IMPLICATIONS AND OTHER COMMENTS

Feature will affect file format. We'll make sure old files are opened correctly after we implement this feature. For old files all parameters will be not constrained in the new "Constraints" tab.

D. EVALUATION

N days.

***

SPECIFICATION
============
PROJECT: File viewer
August 23, 2002

OVERVIEW

It will be application that allows to review and print Program files. Supported file formats:
— v 1
— v 2
— v 3

Viewer will support "Normal" and "Compact" file formats.

Viewer will ignore user's input (mouse click or keyboard input) for all the Program sheets — if user clicks the sheet then just system beep.

SYSTEM REQUIREMENTS

— Windows 98, Me, 2000, NT, XP (version 4.0 or later)
— Any Intel compatible CPU, 100 MHz or higher
— 32 MB or more of RAM
— 2 MB or more of free hard disk space
— a monitor supporting 800×600 resolution or higher

PRINTING

File viewer will allow to print current sheet, current section or entire project.

Always print grids on tables (wysiwyg) and never print the header (wysiwyg, and the printer header is only useful if you are working on a project and need to keep track of dates and files, not an issue if you are printing from a viewer).

STARTUP DIALOG

On launching, instead of the Welcome dialog, Viewer will show a dialog:

—Welcome to the Program viewer —

[text]

[OK]

——————————————————————————

Clicking OK will close the dialog and open File Open dialog (unless they double clicked on a file, so the file is already selected).

MENUS AND COMMANDS

Menus will be the same as in full program.

All menu commands will be the same as in program and grayed, with exception of the following commands:

File: Open, Print Setup, Print, Exit.

Edit: Preferences (See details in PREFERENCES section.)

View: [list of commands]

Change: [list of commands]

Window: [list of commands], [the list of the currently opened documents]

Help: [list of commands]

PREFERENCES

Preferences will be located in the Edit menu.

Preferences content will be the same as in full program, but with all controls grayed with exception of following controls: [list of controls]

TOOLBARS, DOCUMENT NAVIGATION

The toolbars content will be the same as in full program, but all grayed with exception of the following buttons:

Shortcut toolbar: Open, Print

Navigation toolbar: [list]

Formatting toolbar: [list]

Toolbar buttons will have the same tooltips as in full program.

Navigation panel will be the same as in full program, but not editable.

Guide will be off, with no way to turn it on.

Program title bar will contain "…Viewer".

DOCUMENT EXTENSION REGISTRATION

Viewer registers Program files of versions not installed on the computer, so that by double-clicking Viewer opens those files that cannot be opened by program.

DESIGN

"Viewer" will have program icon different from Program.

INSTALLER

Viewer will be installed by InstallProgram to folder "Program Files…Viewer". Installer will create shortcuts on the desktop [name] and in the Start menu [name]. Installer will create uninstalling utility in the Viewer folder and in the "Add/Remove Program" Control Panel.

Сообщения для всех и проверка текстов


Вы наверняка попадали в ситуацию, когда программа отказывается выполнять какую-либо команду, выбрасывает сообщение об ошибке, и, тем не менее, Вы не знаете, что делать дальше, как обойти и решить проблему.

Почему возникают такие тупиковые ситуации? Кто-то скажет: "Так научись пользоваться программой, прочитай руководство пользователя, а потом пользуйся программой!". Или, как вариант: "Изучи технологию сперва и все станет ясно". Некоторые "умники" могут даже сказать: "Что ж тут не ясно?! Надо установить дополнительный модуль Х и только потом выполнять эту команду. Эх, ламер!". Такая установка разработчиков ПО — это демонстрация непрофессионализма.

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

Вот один из характерных, но не самых ужасных, примеров. При попытке открыть определенный (не все) PICT файл в Adobe Illustrator 7 for Macintosh, программа сообщает:

"The MPS parser is unable to parse the file. [OK]"

При этом:

PICT файл успешно открывается в других программах (Picture Viewer, PowerPoint).
PICT файл успешно открывается в новых версиях Illustrator.
Есть вероятность того, что программа У, которая создала PICT файл, не совсем корректно записала определенную информацию, так как другие PICT файлы (с другими наборами объектов на изображении), открываются в Illustrator нормально.
В любом случае, вне зависимости от того, правильный ли PICT или нет, Illustrator (равно как и другие программы) должны выдавать адекватные и понятные сообщения. А что мы видим в данном случае?

"MPS parser". Что такое MPS? Я думаю, что большинство читающих эти строки не знают, что это такое. При этом, так или иначе, пользовались или как минимум запускали Illustrator. Я не являюсь исключением в этом отношении. Подозреваю, что MPS parser — это какой-то Adobe'вский модуль, предназначенный для интерпретации PICT команд. Поверхностный поиск определения "MPS" в Google ничего не дал. Но при этом я встретил много пользователей Illustrator на форумах, которые пытались выяснить, как обойти это сообщение. По большому счету, не так уж и важно обыкновенному пользователю знать, что такое MPS. Но я думаю, многие согласятся, что сокращение "MPS" просто конфузит большинство пользователей, и не дает никакой подсказки или идеи, что ж это за парсер.

"unable to parse". Это уже что-то! Тут Вам уже ясно, что в PICT файле есть что-то, что Illustrator не понимает. Но что? Об этом Adobe почему-то умалчивает. Но ведь эта информация является ключевой для того, чтобы подсказать пользователю, что делать дальше.

Далее… Ну и что, что "unable to parse"? Что это означает? Файл не будет открываться вообще? Или же файл откроется, но без определенных объектов? Не ясно… Не ясно, пока Вы не нажмете ОК в сообщении. А может, для кого-то вызывать это сообщение и нажимать ОК придется несколько раз, чтобы понять, что файл не будет открыт вообще. И, наконец, самое главное…

Что Вам теперь делать? Я думаю, для многих пользователей такое сообщение — это тупик, если не связаться со службой технической поддержки Adobe… или производителя программы У. Это выбор и еще одна неуютная ситуация для пользователя. Особенно если еще учесть, что не часто техподдержка бывает понятной и оперативной, при этом пользователю надо срочно закончить работу с этим PICT файлом… Короче, получаем несчастного пользователя, который недоволен и Adobe, и PICT файлом, и программой Х, и техподдержкой. В итоге, как минимум, у пользователя остается негатив о работе с программой, пользователь жалуется своим коллегам на программу. Или чего хуже — возвращает программу производителю. В любом случае производитель теряет пользователей и деньги.

Вот еще несколько примеров реальных плохих сообщений:

Sorry, the operation could not be completed due to a system error: (Access Denied)
[OK]

Unable to open a required temporary file. Please verify that you have the proper permissions for your system.
[OK]

А вот совсем курьезные сообщения:

CPU not found! Sorry.
[OK] [Report]

Не удалось удалить устройство, поскольку его потомки отклонили запрос на удаление. Возможно, потомки этого устройства необходимы для выполнения загрузки компьютера.
[OK]

Неопределенная ошибка.
[Закрыть] [Подробности]

А чего стоят сообщения типа "Ошибка №45876 [OK]" ?!

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

Как должны выглядеть информативные и понятные сообщения?

По-моему, самые интересные и полезные советы и рекомендации можно найти в руководствах по разработке пользовательского интерфейса от Apple, в частности, в "Руководстве по разработке пользовательского интерфейса Аква" (Aqua Human Interface Guidelines). Я (да и не только) считаю Apple законодателем мод в разработке пользовательских интерфейсов. Также соответствующие разделы по разработке сообщений можно найти в документации от Microsoft, в частности, "Vista UX Guide".

Я следую следующим принципам и приемам в написании сообщений:

1. В общем случае сообщения должны содержать 3 условные части:
    1) Утверждение о том, что произошло. Как правило, это утверждение того, чего не удается сделать, что не будет сделано программой.
    2) Причина проблемы.
    3) Рекомендации как решить, или обойти проблему
    В отдельных простых и очевидных случаях можно комбинировать или опускать эти составляющие.
2. Избегайте сокращений.
3. Сообщения должны быть написаны простым человеческим языком.
4. Сообщения должны быть лаконичными, без лишних технических деталей (если того не требует аудитория).

Таким образом, Адобовское сообщение про "unable to parse" я бы переписал следующим образом:

Cannot open the file.
Adobe Meta Picture Series parser cannot handle data in the file you try to open.
Make sure:
— the file is not corrupted
— Adobe Illustrator is properly installed. You may want to reinstall it.
— You have the latest version of Meta Picture Series parser installed. Check www.adobe.com for it.
Then try to open file again.
[OK]

Сразу уточню, я не знаю, как расшифровать MPS. "Meta Picture Series" — это моя выдумка. Я не знаю всех случаев, когда должно появляться оригинальное сообщение. Я только знаю, что этот парсер "загибается" на определенных последовательностях PICT команд. И это не только ошибка PICT файла, так как новые версии Illustrator открывают этот файл.
Я надеюсь, Вы понимаете, что мои предположение не столь важны для этого примера. В любом случае, обладая полной информацией, можно написать отличное сообщение.

Или как вариант:

Сannot open the file.
The file requires a bigger canvas to display than the maximum canvas size of Illustrator.
Decrease the picture size and try to open the file again.
[OK]

А вот как бы я переписал сообщение про "unable to open a required temporary file":

[Program] cannot run because it cannot create a temporary file.
Either the temporary folder does not exist or it exists but [program] cannot write a file in it (probably the file is write protected).
Location [program] is trying to access: [path]
Check that this folder exists, and that its properties are set to allow programs to create new files within it.
[OK]

Как обеспечить Вашу программу качественными сообщениями?

Вы, как руководитель проекта, должны организовать процесс написания, проверки, корректировки и утверждения сообщений и контролировать его. Сообщения должны соответствовать правилам и рекомендациям по написанию сообщений, таким как, AHIG, APPLE Publications Stye Guide, Vista UX Guide.

Может возникнуть вопрос, а кто должен составлять сообщения. Как правило, сообщения — это результат коллективного труда. Кто как не программист знает, в каких случаях возникает ошибка. Зная причину ошибки, именно программист может обобщить, описать ошибку и рассказать, как ее обойти. Поэтому как минимум, программист должен составить черновой вариант сообщения, который будет отражать суть проблемы и пути ее решения. Хорошо, если инженер корректно и грамотно изложил сообщение. В противном случае, может понадобиться помощь ваша или технического редактора в редактировании текста. Так что учите программистов писать хорошие сообщения. Программисты должны иметь хотя бы общее представление о принципах написания сообщений.

Если же текст составлен на чужом языке, то вам еще понадобиться помощь носителя языка. Ну и в конечном итоге, заказчик должен утвердить или исправить ваше сообщение.

Собирайте все стандартные сообщения в отдельный список, чтобы Вам не приходилось выдумывать сообщения заново для новых продуктов.

Тексты на чужом языке

Дополнительные заботы у вас возникнут, если сообщения нужно составлять на не родном языке. Риск ошибок в текстах увеличивается, если автор не является носителем языка. Вам необходимо убедиться, что все тексты грамматически правильны, используется правильная терминология и стиль написания. Это касается не только сообщений, но и любых текстов в пользовательском интерфейсе вашей программы. Все тексты на чужом языке подлежат проверке носителем языка, если Вам нужно выдать качественный текст. При этом не важно, как хорошо вы или команда знает чужой язык.

Проверять нужно не только новые тексты, но и изменения в уже существующем тексте.

Какие тексты следует проверять помимо текстов сообщений:

— Тексты в окне документа (панели инструментов, панель статуса, и т. д.)
— Подсказки на кнопках панели инструментов, подсказки в диалоговых окнах
— Любые тексты в диалогах
— Окно "О программе"
— Тексты в руководстве пользователя
— Пункты меню
— Тексты на картинках (splash screens)
— Названия папок программы
— Названия файлов программы
— Тексты в шаблонах, примерах и других модулях, поставляемых с программой.
— Тексты, которые автоматически генерируются программой.
— Техническая документация, которую может увидеть заказчик

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

Проверка и корректировка текстов

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

Проверять и корректировать текстов можно как по ходу разработки программы (по мере возникновения необходимости в сообщении), так и все тексты сразу в конце разработки.

Проверка текстов по мере возникновения необходимости имеет смысл, если вы отсылаете регулярные сборки программы заказчику. Если заказчик требует утверждения текстов, то до отсылки программы с новыми текстами заказчику вам следует проверить (в том числе у носителя языка) и откорректировать все новые тексты для конкретной сборки ПО.

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

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

Если же Вы проверяете все тексты сразу, то Вы можете быть более уверенным, что не пропустите какой-либо текст. Второй подход (все сразу) имеет смысл, когда программисты пишут сообщения более-менее нормально, так что вам нужно будет просто пробежаться по тексту и откорректировать мелочи. В реальности следует комбинировать два подхода — "по ходу" и "все сразу". Это позволит сразу писать хорошие сообщения, а потом отловить сообщения, которые проскользнули мимо Вашего внимания.

Защищаемся от вирусов


Очевидно, что информация на проекте по разработке программного обеспечения (далее ПО) требует защиты, в частности, защиты от вирусов и вредоносных программ. Какой бы не был у вас продукт, какой бы не был счастливый у вас заказчик, и какие бы не были профессиональные инженеры у вас на проекте — все вмиг может рухнуть, если вы "отгрузите" заказчику вирус вместе с продуктом, или, что не менее фатально, вы потеряете исходный код продукта. Представьте, что заказчик узнает, что он потерял оплаченные человеко-дни, месяцы или даже годы работы… Я думаю, это ваш страшный сон. Репутация строится годами, а теряется за мгновение. Но как лучше организовать антивирусную защиту? На первый взгляд все вроде как ясно — установил антивирус на компьютеры и все. Однако, не все так просто. Сам по себе антивирус не гарантирует отсутствие вируса на проекте…

В разных компаниях существуют разные процедуры, правила, инструменты для антивирусной защиты и проверки информации. Я же постараюсь описать основополагающие принципы и процедуры по защите информации в небольшой компании на небольшом проекте (скажем размером до 20 человек).

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

Даже если речь идет о больших компаниях-разработчиках ПО с портфелем проектов, то проект — это основная производственная единица, где в первую очередь важно организовать процесс антивирусной защиты или же "заточить" общекорпоративные процессы защиты под потребности и реалии проекта. Например, было бы неправильно в обязательном порядке производить проверку на проекте в 12-00. Это привело б к понижению производительности труда. Член команды должен сам определятся, когда именно он или она сможет проверить свой компьютер. Или же, если производится централизованная удаленная проверка компьютеров, то это также не должно тормозить работу. Но я не об этом…

Вы, как руководитель, отвечаете за свой проект, и вы должны сами убедиться, что все ОК с защитой информации у вас в хозяйстве. Именно вам следует обеспечить процесс защиты и проверки информации на проекте. Целью процесса защиты и проверки, соответственно, должны быть:
1. Минимизация риска проникновения вируса на проект
2. Минимизация потерь, если вирус таки попал на Ваш проект

Вам необходимо определится с такими вопросами (и не только):
— Информационные ресурсы и информационные каналы, которые нужно защитить
— Антивирусное ПО для защиты
— Распределение ответственности в процессе защиты и проверки
— Действия, которые нужно предпринимать для защиты и проверки информации
— Действия, которые нужно предпринимать, если вирус найден
— Отчетность о проверке и контроль

Все участники вашего проекта должны знать и следовать правилам по антивирусной защите. Обязательно новых сотрудников нужно проинформировать об антивирусной защите на проекте. Вы должны организовать контроль над выполнением антивирусных правил. Хорошо, если команда состоит из 2,3…10 человек. В этом случае, процесс можно построить на доверии и достаточно будет просто получать от членов команды подтверждение о том, что компьютеры проверены и не содержат вирусов. А если в команде десятки человек? Большинство людей самосознательны, но вы не застрахованы от того, что кто-то пропустит мероприятия по защите, то ли по не знанию, то ли по халатности. Поэтому, простых подтверждений может и не хватить — нужно вводить процедуру аудита. Как правило, такой аудит проводят "независимые органы", например, сотрудники отдела ИТ. Они могут проводить плановые или внеплановые проверки… Но не об этом речь.

Что защищать?

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

Как вирусы могут попасть на проект?

— По почте и программам мгновенных сообщений. То ли это внутренняя проектная почта, то ли это внешняя корпоративная почта — любую почту нужно защищать. Приложения к почте от неизвестных отправителей лучше не открывать.
— Веб. По ходу работы участники проекта могут забредать в такие уголки всемирной путины, лазить по таким сомнительным веб-страницам, что сложно себе представить, что там можно подхватить.
— ФТП, торренты и другие файлообменники. Не редко приходится обмениваться данными с заказчиком с помощью его, ваших или публичных ФТП-серверов. Также по ходу разработки наверняка понадобится загружать программы, библиотеки, код и другую информации с торрентов и файлообменников. Все эти ресурсы могут быть (и чаще всего являются) разносчиками вредоносных программ и вирусов.
— Устройства для хранения и переноса данных, такие как CDs, DVDs, флеш-память, ZIP и гибкие диски, фото-видео камеры, mp3-плееры, USB часы, сотовые телефоны и другие устройства для хранения и переноса данных, которые могут быть присоединены к компьютерам. Эти устройства как личные, так и корпоративные могут использоваться на проекте, как в производственных целях, так и в частных.

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

Чем защищать и проверять?

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

Убедитесь, что команде всегда доступны последние антивирусные базы и обновления АВ-программам. Установите на проекте процесс обязательного и регулярного (скажем, раз в месяц) обновления вирусных баз.

Если говорить о конкретных АВ-программах, то по опыту могу сказать, что бесплатными АВ-программами лучше пользоваться как дополнительным, но не как основными средством защиты. Я имею ввиду не условно бесплатные антивирусы — взломанные, а бесплатные по определению. "Бесплатный сыр — только в мышеловке". Не думаю, что бесплатный антивирус обеспечит более высокий уровень защиты, чем популярный и платный. Также избегайте параноидальные АВ-программы, которые "ругаются" на все по их мнению подозрительное, включая абсолютно чистое, коммерческое ПО. Был у меня случай, когда популярный платный антивирус начал ругаться на нашу программу. Проблема была в чересчур чувствительной эвристической проверке. Производитель АВ-программы вскоре после нашей жалобы исправила проблему.

С одной стороны, параноидальный антивирус может вам доставить много ненужной суеты, но с другой стороны, лучше перебдеть, чем недобдеть. Короче, обратите внимание на популярные, платные АВ-программы, именитых производителей.

Также можно иногда проверять файлы антивирусными веб-сервисам, которые проверяют ваш файл десятками АВ-программ. Особенно имеет смысл делать такие проверки перед выпуском продукта заказчику. Однако такие проверки стоит согласовывать с заказчиком.

Как проверять?

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

— Автоматическое лечение файлов
— Карантин, если лечение не возможно
— Сканирование архивов
— Проверка всего диска по требованию
— Автоматическое сканирование внешние диски

Если компьютер подсоединен в Интернет, то имеет смысл установить файрвол, и автозащиту.

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

Устройства для хранения и переноса данных

Вопрос об устройствах для хранения и переноса данных — деликатен. Очевидно, что команде не запретишь приносить на рабочее место фото камеры, mp3-плееры, USB часы. Но с другой стороны эти устройства являются потенциальными хранителями вирусов и вредоносных программ, которые случайно (а может и специально) могут попасть на проектное оборудование.

У меня был случай, когда один из сотрудников пришел в субботу на работу с ребенком. Сам сел работать, а ребенку поставил диск с мультиком. В понедельник полкоманды до 2 часов ночи чистили компьютеры от вируса. Вирус попал на проект через автозапуск на диске с мультиком, который смотрел ребенок. Диск был куплен на базаре.

Что можно сделать, чтоб избежать таких и более серьезных форс-мажоров? Тут нет серебряной пули, и подходить нужно комплексно. Среди мер могут быть:
— Разрешить пользоваться CDs, DVDs, флеш-памятью, ZIP и гибкими дисками и другими носителями информации, только с вашего разрешения.
— Если необходимо использовать на проекте носитель информации, в обязательном порядке проверять носители антивирусами.
— Установить на компьютере автопроверку носителей информации АВ-программой.
— Запретить создавать соединения между передатчиками (например, bluetooth модем в телефоне) и проектными компьютерами в личных целях.

Можно обязать сотрудника подписать договор о неразглашении, в котором изложить правила поведения с носителями и передатчиками информации.

Однако большинство таких мероприятий послужат только барьером от случайного проникновения вирусов на проект или от проникновения вирусов по халатности. Но если кто-то сознательно решил нанести вред информации, то эти барьеры вряд ли будут действенными. Не буду рассматривать такие драконовские методы контроля как камеры для слежения за сотрудниками, тотальный мониторинг компьютеров разработчиков, какие-либо физические барьеры (досмотров на входе/выходе) и другие параноидальные меры. Разработчики ПО — это творческие и интеллектуальные люди, которые просто не будут эффективно работать в таких условиях. А этого вы, как руководитель проекта, определенно не хотите.

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

Когда проверять?

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

Что делать когда когда обнаружен вирус?

Вам четко нужно знать какие шаги предпринимать, в случае если на проекте обнаружился вирус. Вы всегда должны иметь готовый план и алгоритм действий, дабы минимизировать ущерб от деятельности вируса и минимизировать распространение вируса по проекту и за его пределами. Как минимум имеет смысл сделать следующее:

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

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

Приобретение программного обеспечения


Наверняка перед вами возникал вопрос о приобретении 3-партийного программного обеспечения для разработки или тестирования вашего продукта. Для большинства украинских компании, особенно для тех, которые работают на внутренний рынок — это пока не большая проблема. Вышел в переход (или на Петровке) и купил себе за 7-15 гривен то, что в цивилизованных страхах стоит сотни и тысячи "вечно зеленых".

(Петровка — это большой книжный рынок в Киеве, где также продается пиратский софт.)

"Бесплатный" софт наряду с более дешевой рабочей силой являются большим конкурентным преимуществом украинских компании на мировом рынке разработки программного обеспечения.

Например, возьмем минимальный набор программиста:

$150 MS Windows XP Professional
$799 MS Visual Studio .NET 2003
$364 MS Office XP Professional
$299 File Maker Pro 7 (база данных для учета ошибок, далее баго-база)
$1612 ИТОГО
А если учесть, что рабочих мест несколько? Скажем 10. С учетом скидок на многолицензионные пакеты у нас получится до $16120. Рабочих мест может быть еще больше…

Теперь, посмотрим на то, что может понадобится ДОПОЛНИТЕЛНО для разработки полноценного продукта средней сложности (трудоемкостью в ХХ.Х человеко-месяцев) для конечного потребителя.

$1399 InstallShield 10.5 Professional (продукту нежен инстолер)
$999 File Maker Server 7 (для баго-базы)
$1199 MSDN Professional (программисты должны быть всезнайками)
$649 Adobe PhotoShop CS (для продукта нужны иконки, эскизы…)
$299 Adobe Acrobat 7 Standard (для продукта нужна документация)
$499 Adobe Page Maker 7 (…"документация" говорю)
$39 Antivirus Kaspersky Personal (вирусов нам не надо)
$599 MS Project Standard 2003 (ну и чтоб управлялось хорошо)
$5682 ИТОГО

Итого, из расчета команды из 10 человек, у нас получается до $21694.

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

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

И вы, как руководитель проекта, должны исходить из предположения, что у вас на проекте все должно быть легально (даже если ваша компания не всегда может себе позволить легально покупать программы).

Поэтому поговорим о правильных вещах…

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

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

Если же речь идет о специфических программах или новых версиях базовых программ, то руководству регулярно приходится решать вопросы: "А действительно ли нам нужен продукт Икс?", "А может, достаточно Демо или Триал (Trial) версии продукта Икс?", "А нужен ли продукт Икс нам или заказчику?", "Если заказчику, то может пусть сам возьмет и купит?", "А может, все-таки Петровка?"

Как мы определились, по последнему вопросу у вас, как у руководителя проекта, должна быть однозначная позиция — "Ганьба! Ні пиратству! Пиратство геть!". Если высшее руководство настаивает, то это будет их решение. И с вас ответственность снимается в случае чего. Особенно такая позиция актуальна в компаниях, которые работают на зарубежных цивилизованных заказчиков. Если вы работаете в честной компании, то читайте дальше…

Вам необходимо будет доказать высшему руководству (или тем, кто отвечает за закупки), что продукт действительно нужен.

Очевидно, если заказчик просто требует, или ваш продукт может использоваться совместно с другим продуктом, или, не дай Бог, пользователи уже начали жаловаться, что ваш продукт не совместим или плохо совместим с другим продуктом, то вам просто необходим этот 3-партийный продукт. Это абсолютно веские аргументы в пользу необходимости проверки на совместимость. Но тут надо решать: можно ли обойтись демо или триал версиями. Что может и ответить ваше руководство: "А зачем нужна полная версия продукта?! Возьми демо или триал".

Почему Демо или Триал не всегда подходят?

Пример: Мы разрабатываем продукт, который строит графики по неким данным. При этом, программа не приспособлена к подготовке презентаций. Не редко для презентаций потребители используют MS PowerPoint.

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

2. Триал. Тут ситуация несколько сложнее. Как правило, Триал версии полнофункциональны, но ограничены по времени. Поэтому, тут надо считать, будут ли затраты на покупку полной версии меньшими, чем затраты на регулярную переустановку Демо версии. Если полную версию купить дешевле, чем тратить время команды на переустановки, то лучше все-таки покупать.

Затраты на переустановку зависят от:

а) длительности работы триал версии.

б) срока, на который нужен продукт. Если на несколько дней, а триал работает месяц, то вопрос закрыть.

в) времени на переустановку продукта на одном рабочем месте.

г) количества рабочих местах, на которых нужно переустанавливать программу.

д) стоимости рабочего часа программиста или тестера.

Рассмотрим наш пример с PowerPoint. Предположим, проблема заключается в том что, графики нашей программы выглядят плохо на экране в новой версии PowerPoint.

а) Триал версия PowerPoint работает 1 месяц.

б) PowerPoint нужен нам на длительный период, так как обращения в тех. поддержку по поводу разных проблем совместимости приходят регулярно (несколько раз в неделю). Для нашего примера, мы ограничимся временем до выхода новой версии PowerPoint, скажем, 2 года (24 месяца).

в) Мы не можем взять так сразу и переустановить PowerPoint. PowerPoint записывает регистрацию глубоко в реестре и каталогах. Надо переустанавливать ОС. А это, как мы знаем, дело небыстрое. А если учесть, что еще необходимо время на установку всех необходимых программ, установок, опций… то есть полностью восстановить рабочее окружение, то на переустановку PowerPoint может уйти до 1 дня.

г) Скажем, у нас команда из 4 человек: 2 тестера и 2 программиста.

д) Думаю, в компании, которая покупает официальный софт, программисты дорогие. Предположим, $4 в час.

Итого, посчитаем затраты 2 программистов в течение 2х лет на переустановку PowerPoint:

24 (месяца) х 8 (часов на переустановку) х 2 (программиста) х $4 (в час) = $1536

Посчитаем тестеров:

24 (месяца) х 8 (часов на переустановку) х 2 (тестера) х $1 (в час) = $384

Вся команда — $1920.

Итого, за два года переинсталяции PowerPoint фирма потеряет $1556 ($1920 — $364 стоимость Офиса). Даже если учесть, что одна переустановка может занять в 2 раза меньше (часа 4), то затраты на переустановку все равно больше ($960), чем стоимость MS Office ($364).

А рабочих мест может быть десятки, если одновременно запущены много проектов. Поэтому, как видим, использование триал версии не всегда экономически выгодно. И решение (о покупке полной версии) всегда зависит от того, что дешевле, купить или потратить время. А это в свою очередь зависит от стоимости рабочего времени, количества рабочих мест где нужна программа, и на сколько времени нужна программа.

"Если это нужно для заказчика, то пусть он сам и покупает."

Иногда причина противодействия высшего руководства и владельцев компании по поводу покупки софта может заключаться в политике компании. Вы должны это знать и понимать. Когда вы доказали, что программа действительно нужна, ваше начальство может ответить "Ну, если это надо заказчику, то пусть он и покупает этот продукт. Проси заказчика." По идее это правильно, и так должно быть в принципе, но не всегда. Представьте себе, вы говорите заказчику: "Мы профессионалы по разработке программных продуктов на платформе Windows". Заказчик думает: "О! Наконец-то я нашел спецов! Буду разрабатывать свои продукт у них". А потом вы ему говорите. "Знаешь, Боб, нам нужен MS Office XP!". И тут заказчик думает: "Как так?! Профессионалы… нужен MS Office XP… ?!?!?". Политически не корректно. И вы должны объяснить это руководству.

Ах, да, еще… все эти расчеты должны делать вы, как руководитель проекта. Если у вас в компании предусмотрен человек по закупке софта, он не всегда будет самостоятельно считать и усердно отстаивать ваши интересы. Еще бы! Не ему же Офис нужен! А именно такие расчеты могут убедить топ менеджмент (и владельцев) в актуальности покупки. К тому же, вы Бог и Царь на вашем проекте и вы вправе (если вы на 100% уверены,что ваш проект страдает) поднимать вопрос на самом высшем уровне.

24/2/2005