С сожалением был вынужден ввязаться в дискуссию которая развернулась на форуме uml2.ru http://www.uml2.ru/forum/index.php?topic=4634.0 по поводу статьи А. Новичкова и Ко об ИТ и психологии. Для меня было интересным не столько сама публикация, сколько развернувшаяся дискуссия (хотя дискуссией ЭТО назвать достаточно сложно). Лишний раз убеждаюсь в справедливости утверждения, что там где одни видят проблемы - другие видят возможности. Тема психологии и отношений в ИТ командах на текущий момент в России особо не раскручена - не упакована как следует и не подана как товар. Я еще в свою бытность фрилансером на полном серьезе обдумывал при комплексном обучении аналитиков давать им определенные навыки психологии общения (с заказчиком и с коллегами-разработчиками). Даже помнится с Александром Байкиным мы обсуждали эту тему с одной дамой, которая делала тренинги по "психологии в бизнесе". И вот эта тема получила продолжение в том, чем занимается Александр Новичков. В то же время, один из участников дискуссии, занимающийся обучением аналитиков, в форме, далекой от цивилизованной дискуссии банально охаивал данную публикацию А. Новичкова. Я честно порекомендовал коллеге вместо "наезда" использовать эту тему и совместно с автором "доточить", упаковать и довести до состояния товара - давая дополнительные знания аналитикам. Однако коллега столь сильно увлекся самовыражением, что перестал воспринимать здравые рекомендации по расширению собственного же бизнеса - пытаясь не оставить камня на камне от публикации и автора лично. Эмоции вредят бизнесу, так же как и позиция видения проблем, там где можно найти возможности .... Хотя не удивлюсь, если через некоторое время в курсе коллеги появится соответствующий раздел о психологии общения и т.п. .... .
четверг, 23 февраля 2012 г.
Изменения в карьере .... не опять, а снова :-)
Что-то я забросил свой блог совсем. Признаться времени с середины прошлого года не было вообще .... проекты сплошняком (особенно запомнилась работа по проекту НПРОД ;-))). А потом смена работы ... да, я перешел в ноябре 2011 года в компанию Microsoft, на позицию Account Technology Strategist (честно говоря я сам не понимаю как это перевести адекватно на русский, хотя у меня есть несколько идей ... - может у кого еще есть идеи ?). Теперь занимаюсь, скажем так, технологическим развитием конкретных заказчиков (за которых отвечаю я в паре с Account Manager) из банковского сектора и страховых компаний ....
Вообще идея иметь выделенного человека в конкретных заказчиках, который бы помогал этим заказчикам с применением технологий вендора (на стратегическом уровне, а не на уровне техподдержки) и находил новые opportunities сама по себе очень правильная. По сути, это реализация стратегии win-win в "игре" м/у вендорами и заказчиками.
Вообще идея иметь выделенного человека в конкретных заказчиках, который бы помогал этим заказчикам с применением технологий вендора (на стратегическом уровне, а не на уровне техподдержки) и находил новые opportunities сама по себе очень правильная. По сути, это реализация стратегии win-win в "игре" м/у вендорами и заказчиками.
вторник, 3 мая 2011 г.
Полезные ссылки на бронирование отелей, прокат автомобилей, авиабилеты и т.д.
Все тут: http://smarttravel.livejournal.com/ ... лично я воспользовался советами ... :-)
пятница, 18 февраля 2011 г.
Про "большое Сколково" ...
Озаглавил именно как "большое Сколково", т.к. уже несколько раз сталкивался с тем, что многие ассоциируют МШУ Сколково и "инноград" Сколково, считая что это одно и то же. Приходится пояснять, что это разные организации. Подумалось, что они разные даже по своей идее - если МШУ это скорее исследования в области развивающихся рынков, цель же иннограда, на мой взгляд, именно вытащить нас всех из этого вечного "развития" в светлое будущее "развитого капитализма" :-). Но собственно мне всегда было интересно, как "на западе", на фоне сообщений о намерениях и подписанных договорах с большими корпорациями все-таки относятся к этому проекту иннограда. В "бытовых" разговорах/переписке, мало кто из моих собеседников высказывался оптимистично по поводу перспектив большого Сколково. А тут, однажды слушая в машине радио наткнулся на передачу по Финам, в которой для беседы были приглашены два западных журналиста (одна из них - дама, как я понял родилась в России). Рассуждали про Россию и ее имидж в мире и т.п. Когда их спросили как вообще настроение на западе по их ощущениям в отношении большого Сколково - я получил лишнее подтверждение "бытовой" точке зрения - не верят в этот проект на западе. Почему меня это не удивляет?
понедельник, 13 декабря 2010 г.
Возвращаясь к вопросу о use cases и функциях ...
Читая форум UML2.RU, натолкнулся на дискуссию о том что функции системы дублируют юзкейсы, и вообще не понятно что есть что и для чего, кроме этого такие же вопросы иногда возникают у коллег по работе, и у заказчиков, для которых в силу специфики их систем, я разрабатываю еще и модель вариантов использования (Use Cases).... В данной заметке я решил дать краткое пояснение по данному вопросу, не слишком вдаваясь в формальные определения, а больше по сути вопроса.
Юзкейсы (Use Cases, варианты использования) - это взгляд с т.з. пользователя на систему, который дает ответ на вопрос какие свои задачи (в терминах того же Коберна - цели) решает пользователь при помощи системы, и что при этом делает система в ответ на действия пользователя. Юзкейсы относятся к т.н. "пользовательским требованиям" (по "классификации" Вигерса).
Функции - это некие свойства системы, или нечто полезное, что может делать система, в т.ч. для внешнего по отношению к ней пользователя. Функции системы - это, если так можно выразиться, взгляд "изнутри" системы на ее окружение. Кстати, говорить о функциях системы можно только на этапе ее проектирования. Т,е. когда речь идет о том, что эти функции уже определены и мы их перечисляем, и поясняем механизм их реализации. На этапе требований - можно говорить только о ТРЕБОВАНИЯХ к функциям (или иначе - функциональным требованиям). Т.е. на этапе разработки требований, функций системы как самостоятельных артефактов еще нет, есть только требования к ним!
О разнице м/у юзкейсами и функциями. Юзкейсы не являются функциями а) по-определению б) по своей природе. Поясню на примере - юзкейсом для системы управления корпоративной печатью вполне может быть, например, "Распечатать документ" - это цель пользователя, явная и достаточно крупная. В то же время функцией такой системы может быть "Авторизация пользователя на устройстве печати посредством смарт-карты", или "Удаление заданий из очереди печати (после распечатки)", но таких юзкейсов у системы не будет (как минимум в данном контексте). Еще одной отличительной чертой является то, что функции, в отличии от юзкейсов, могут иметь жесткую иерархию, и могут быть декомпозированы (т.е. двигаясь вниз по иерархии - они будут детализировать "верхнюю" функцию).
Основной вопрос возникает как совмещать оба подхода при разработке требований к системам. И как не допускать явного дублирования. Тут есть несколько подходов.
Есть подход "a-la RUP", в котором юзкейсы могут рассматриваться как основа требований, и дальше разрабатывается только доп. спецификация - в которой описываются те аспекты (часть функциональных требований и нефункциональные требования), которые не затронуты юзкейсами и производится трассировка их на юзкейсы.
Есть подход Вигерса - где наряду с юзкейсами описывается полноценное SRS, в котором перечисляются именно функциональные требования и они так же, могут быть оттрассированы на юзкейсы.
Есть подход без использования юзкейсов - когда можно описать всю возможную функциональность в виде иерархического списка функциональных требований, и при этом вполне могут быть такие высокоуровневые функции (для той же системы управления печатью), как "Печать документа", "Копирование документа", и т.п, которые просто будут декомпозированы. А если при этом распределить эти функции по типам пользователей, то в принципе можно получить представление о том, каким пользователям какая функциональность доступна. При этом можно говорить о формулировке требований в формате "Система должна иметь возможность ..." и "Пользователь должен иметь возможность...". В этом случае можно высокоуровневыми требованиями сделать a-la пользовательские ("Пользователь должен иметь возможность..."), и декомпозировать их чисто функциональными ("Система должна иметь возможность ...").
В любом случае, если есть сомнение "to Use Case or not ...", следует четко понимать, какую дополнительную ценность принесут юзкейсы, не только для разработки требований, но и для проектирования, тестирования и проведения приемо-сдаточных испытаний. И исходя из этого принимать решение, какой из подходов использовать.
Юзкейсы (Use Cases, варианты использования) - это взгляд с т.з. пользователя на систему, который дает ответ на вопрос какие свои задачи (в терминах того же Коберна - цели) решает пользователь при помощи системы, и что при этом делает система в ответ на действия пользователя. Юзкейсы относятся к т.н. "пользовательским требованиям" (по "классификации" Вигерса).
Функции - это некие свойства системы, или нечто полезное, что может делать система, в т.ч. для внешнего по отношению к ней пользователя. Функции системы - это, если так можно выразиться, взгляд "изнутри" системы на ее окружение. Кстати, говорить о функциях системы можно только на этапе ее проектирования. Т,е. когда речь идет о том, что эти функции уже определены и мы их перечисляем, и поясняем механизм их реализации. На этапе требований - можно говорить только о ТРЕБОВАНИЯХ к функциям (или иначе - функциональным требованиям). Т.е. на этапе разработки требований, функций системы как самостоятельных артефактов еще нет, есть только требования к ним!
О разнице м/у юзкейсами и функциями. Юзкейсы не являются функциями а) по-определению б) по своей природе. Поясню на примере - юзкейсом для системы управления корпоративной печатью вполне может быть, например, "Распечатать документ" - это цель пользователя, явная и достаточно крупная. В то же время функцией такой системы может быть "Авторизация пользователя на устройстве печати посредством смарт-карты", или "Удаление заданий из очереди печати (после распечатки)", но таких юзкейсов у системы не будет (как минимум в данном контексте). Еще одной отличительной чертой является то, что функции, в отличии от юзкейсов, могут иметь жесткую иерархию, и могут быть декомпозированы (т.е. двигаясь вниз по иерархии - они будут детализировать "верхнюю" функцию).
Основной вопрос возникает как совмещать оба подхода при разработке требований к системам. И как не допускать явного дублирования. Тут есть несколько подходов.
Есть подход "a-la RUP", в котором юзкейсы могут рассматриваться как основа требований, и дальше разрабатывается только доп. спецификация - в которой описываются те аспекты (часть функциональных требований и нефункциональные требования), которые не затронуты юзкейсами и производится трассировка их на юзкейсы.
Есть подход Вигерса - где наряду с юзкейсами описывается полноценное SRS, в котором перечисляются именно функциональные требования и они так же, могут быть оттрассированы на юзкейсы.
Есть подход без использования юзкейсов - когда можно описать всю возможную функциональность в виде иерархического списка функциональных требований, и при этом вполне могут быть такие высокоуровневые функции (для той же системы управления печатью), как "Печать документа", "Копирование документа", и т.п, которые просто будут декомпозированы. А если при этом распределить эти функции по типам пользователей, то в принципе можно получить представление о том, каким пользователям какая функциональность доступна. При этом можно говорить о формулировке требований в формате "Система должна иметь возможность ..." и "Пользователь должен иметь возможность...". В этом случае можно высокоуровневыми требованиями сделать a-la пользовательские ("Пользователь должен иметь возможность..."), и декомпозировать их чисто функциональными ("Система должна иметь возможность ...").
В любом случае, если есть сомнение "to Use Case or not ...", следует четко понимать, какую дополнительную ценность принесут юзкейсы, не только для разработки требований, но и для проектирования, тестирования и проведения приемо-сдаточных испытаний. И исходя из этого принимать решение, какой из подходов использовать.
воскресенье, 17 октября 2010 г.
Не удалось посетить SECR-2010. Я много потерял?
В этом году мне не удалось посетить конференцию SECR-2010. Честно говоря, когда я посмотрел ее программу, лично у меня она не вызвала явного интереса. Судя по некоторым отзывам - http://blogs.uml2.ru/post/SECR-2010-pervye-vpechatleniya как-то безрадостно.... Неужели все идет по принципу "Что может быть хуже чем Робот-полицейский-2?" - "Робот-полицейский-3!!!"? Интересно было бы узнать мнения посетивших ....
вторник, 5 октября 2010 г.
Почитал заметку про реакцию на новую школьную программу по информатике ...
Тут http://cnews.ru/news/top/index.shtml?2010/10/04/410981 опубликована заметка про реакцию "представителей ИТ-сообщества" на новую школьную программу по информатике. Не перестаю удивляться нашим академикам от образования ... зачем детям такой объем знаний? Больше всего мне нравятся заявления про то, что большую часть времени преподавание информатики может происходить без компьютеров (по этой программе)! Видимо авторы программы не в курсе про инициативы правительства об информатизации школ и т.п. Интересно, какие задачи призвана решать такая программа образования? Кого готовить? Будущих студентов ИТ-специальностей ВУЗов?
IMHO, на теоретические аспекты по информатике следует отдавать не более 20% времени. Более ценным для школьников было научить их печатать вслепую (страшно смотреть, когда молоденькая операционистка в банке, тычет одним пальцем, набирая мою платежку ..., а ведь изучала в школе информатику!). И научить использовать текстовые редакторы и электронные таблицы для решения прикладных задач (да хоть на примере учета расхода собственных карманных денег). Это бы позволило решить вопрос элементарной компьютерной грамотности и в большей степени способствовало бы информатизации образования, как такового. Глядишь, доживем до счастливого момента, когда ученики будут отправлять рефераты учителю по e-mail :-).
IMHO, на теоретические аспекты по информатике следует отдавать не более 20% времени. Более ценным для школьников было научить их печатать вслепую (страшно смотреть, когда молоденькая операционистка в банке, тычет одним пальцем, набирая мою платежку ..., а ведь изучала в школе информатику!). И научить использовать текстовые редакторы и электронные таблицы для решения прикладных задач (да хоть на примере учета расхода собственных карманных денег). Это бы позволило решить вопрос элементарной компьютерной грамотности и в большей степени способствовало бы информатизации образования, как такового. Глядишь, доживем до счастливого момента, когда ученики будут отправлять рефераты учителю по e-mail :-).
Подписаться на:
Сообщения (Atom)