Анатолий Карачинский и Цукерберг ...

Таки да, бросилась в глаза заметка на CNews http://www.cnews.ru/top/2012/09/28/glava_ibs_potryasen_chto_cukerbergu_ne_stydno_vstrechatsya_s_medvedevym_504718 про возмущение основателя IBS предложением Facebook по "эвакуации талантов". Только мне не вполне понятны мотивы для такого возмущения ... анализируя возможные причины, можно предположить следующее:
1. А. Карачинскому "за державу обидно", т.е. имеем ментальные причины
2. У возмущения есть материальные причины ...

Зная специфику работы наших системных интеграторов особенно с госсектором, в духовность и прочия как-то не очень верится. А вот сожаление, что кто-то соблазнится на более комфортные условия жизни из тех, на труде которых компания сейчас зарабатывает - это вполне понятный повод для возмущения.
Тут можно много говорить о том, что и в России талантливые разработчики могут хорошо зарабатывать, но жить все-равно комфортнее там - и инфраструктура лучше и климат теплее и медицина лучше, да и продукты питания можно выбирать ОРГАНИК и даже при продажи рыбы в магазине понятно ее происхождение - дикая или выращенная на ферме... Так что тут можно не обсуждать тему....

Еще один аргумент возмущающихся - это полученное якобы за счет государства образование, которое талантливый выпускник вуза не отработал. Тут вот хотелось бы разораться ... Коль скоро ВУЗ был государственный, значит существовал в т.ч. на налоги родителей выпускника. Тогда получается, что за образование ребенка родители уже заплатили своими налогами? Тогда какие претензии?

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

Не попал на ЛАФ 2012 :-(

Только вернулся из отпуска ... к сожалению не смог попасть на ЛАФ 2012 в Иваново. Надеюсь на следующий год получиться!

О дискуссии по поводу статьи А. Новичкова и Ко на uml2.ru/

С сожалением был вынужден ввязаться в дискуссию которая развернулась на форуме uml2.ru http://www.uml2.ru/forum/index.php?topic=4634.0 по поводу статьи А. Новичкова и Ко об ИТ и психологии. Для меня было интересным не столько сама публикация, сколько развернувшаяся дискуссия (хотя дискуссией ЭТО назвать достаточно сложно). Лишний раз убеждаюсь в справедливости утверждения, что там где одни видят проблемы - другие видят возможности. Тема психологии и отношений в ИТ командах на текущий момент в России особо не раскручена - не упакована как следует и не подана как товар. Я еще в свою бытность фрилансером на полном серьезе обдумывал при комплексном обучении аналитиков давать им определенные навыки психологии общения (с заказчиком и с коллегами-разработчиками). Даже помнится с Александром Байкиным мы обсуждали эту тему с одной дамой, которая делала тренинги по "психологии в бизнесе". И вот эта тема получила продолжение в том, чем занимается Александр Новичков. В то же время, один из участников дискуссии, занимающийся обучением аналитиков, в форме, далекой от цивилизованной дискуссии банально охаивал данную публикацию А. Новичкова. Я честно порекомендовал коллеге вместо "наезда" использовать эту тему и совместно с автором "доточить", упаковать и довести до состояния товара - давая дополнительные знания аналитикам. Однако коллега столь сильно увлекся самовыражением, что перестал воспринимать здравые рекомендации по расширению собственного же бизнеса - пытаясь не оставить камня на камне от публикации и автора лично. Эмоции вредят бизнесу, так же как и позиция видения проблем, там где можно найти возможности .... Хотя не удивлюсь, если через некоторое время в курсе коллеги появится соответствующий раздел о психологии общения и т.п. .... .

Изменения в карьере .... не опять, а снова :-)

Что-то я забросил свой блог совсем. Признаться времени с середины прошлого года не было вообще .... проекты сплошняком (особенно запомнилась работа по проекту НПРОД ;-))). А потом смена работы ... да, я перешел в ноябре 2011 года в компанию Microsoft, на позицию Account Technology Strategist (честно говоря я сам не понимаю как это перевести адекватно на русский, хотя у меня есть несколько идей ... - может у кого еще есть идеи ?). Теперь занимаюсь, скажем так, технологическим развитием конкретных заказчиков (за которых отвечаю я в паре с Account Manager) из банковского сектора и страховых компаний ....
Вообще идея иметь выделенного человека в конкретных заказчиках, который бы помогал этим заказчикам с применением технологий вендора (на стратегическом уровне, а не на уровне техподдержки) и находил новые opportunities сама по себе очень правильная. По сути, это реализация стратегии win-win в "игре" м/у вендорами и заказчиками. 

Полезные ссылки на бронирование отелей, прокат автомобилей, авиабилеты и т.д.

Все тут: http://smarttravel.livejournal.com/ ... лично я воспользовался советами ... :-)

Про "большое Сколково" ...

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

Возвращаясь к вопросу о use cases и функциях ...

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


Юзкейсы (Use Cases, варианты использования) - это взгляд с т.з.  пользователя на систему, который дает ответ на вопрос какие свои задачи (в терминах того же Коберна - цели) решает пользователь при помощи системы, и что при этом делает система в ответ на действия пользователя. Юзкейсы относятся к т.н. "пользовательским требованиям" (по "классификации" Вигерса).
Функции - это некие свойства системы, или нечто полезное, что может делать система, в т.ч. для внешнего по отношению к ней пользователя. Функции системы - это, если так можно выразиться, взгляд "изнутри" системы на ее окружение. Кстати, говорить о функциях системы можно только на этапе ее проектирования. Т,е. когда речь идет о том, что эти функции уже определены и мы их перечисляем, и поясняем механизм их реализации. На этапе требований - можно говорить только о ТРЕБОВАНИЯХ к функциям (или иначе - функциональным требованиям). Т.е. на этапе разработки требований, функций системы как самостоятельных артефактов еще нет, есть только требования к ним!

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

Основной вопрос возникает как совмещать оба подхода при разработке требований к системам. И как не допускать явного дублирования. Тут есть несколько подходов.
Есть подход "a-la RUP", в котором юзкейсы могут рассматриваться как основа требований, и дальше разрабатывается только доп. спецификация - в которой описываются те аспекты (часть функциональных требований и нефункциональные требования), которые не затронуты юзкейсами и производится трассировка их на юзкейсы.
Есть подход Вигерса - где наряду с юзкейсами описывается полноценное SRS, в котором перечисляются именно функциональные требования и они так же, могут быть оттрассированы на юзкейсы.
Есть подход без использования юзкейсов - когда можно описать всю возможную функциональность в виде иерархического списка функциональных требований, и при этом вполне могут быть такие высокоуровневые функции (для той же системы управления печатью), как "Печать документа", "Копирование документа", и т.п, которые просто будут декомпозированы. А если при этом распределить эти функции по типам пользователей, то в принципе можно получить представление о том, каким пользователям какая функциональность доступна. При этом можно говорить о формулировке требований в формате "Система должна иметь возможность ..." и "Пользователь должен иметь возможность...". В этом случае можно высокоуровневыми требованиями сделать a-la пользовательские ("Пользователь должен иметь возможность..."), и декомпозировать их чисто функциональными ("Система должна иметь возможность ...").

В любом случае, если есть сомнение "to Use Case or not ...", следует четко понимать, какую дополнительную ценность принесут юзкейсы, не только для разработки требований, но и для проектирования, тестирования и проведения приемо-сдаточных испытаний. И исходя из этого принимать решение, какой из подходов использовать.