[icon] Системный анализ в Разработке ПО и Другие
View:Recent Entries.
View:Archive.
View:Friends.
View:User Info.
View:Website (Профиль в Моём Круге).
View:Блог избранного на beskov.ru. UML 2 • RU.
Любимые ЖЖ-сообщества:Бизнес- и системный анализ. Системные архитекторы. User-centered Design. Управление проектами. Web 2.0.
You're looking at the latest 20 entries.
Missed some entries? Then simply jump back 20 entries

Advertisement

Subject:26 ноября, МСК — Семинар «Разработка концепции ПО»
Time:03:38 am
При выполнении проекта по разработке ПО почти всегда речь идет только о документе «техническое задание». Однако существует другой, не менее важный документ, предшествующий техническому заданию — это концепция.

Темы данного семинара:
1. Понятие концепции (vision). Место концепции в жизненном цикле разработки ПО
2. Взаимосвязь концепции с артефактами проекта по разработке ПО
3. Структура концепции
4. Примеры документа "концепция" в различных методологиях разработки ПО
5. А у нас все не так! (ответы на вопросы)

Докладчики: Векленко Ирина и Сурова Ирина

Дата и время проведения: 26 ноября 2009 года с 19:00 до 21:30

Место проведения: Москва, Архангельский переулок, 1/1/9, строение 1, офис 423. Компания «Заказные ИнформСистемы».

Регистрация
comments: 3 comments or Leave a comment Add to Memories Tell a Friend

Subject:12 и 14 ноября празднуем Всемирный День Юзабилити — Семинар + Конференция
Time:09:25 am
12 ноября отмечается Всемирный День Юзабилити (см. http://worldusabilityday.org).
Этот праздник проходит уже в пятый раз по всему миру.
В этот же день на сайте WorldUsabilityDay.ru состоится онлайн-семинар Аарона Маркуса.


А 14 ноября, в субботу, в Москве пройдёт бесплатная конференция World Usability Day 2009, посвященная этому празднику.
На неё приглашены в качестве докладчиков: Влад Головач, Артем Горбунов, Андрей Бибичев и другие известные специалисты —
всего будет 11 докладов, а также несколько блиц-докладов и мастер-классы от Екатерины Сугак и Дмитрия Сатина.

Полный текст программы можно посмотреть на wud2009.ru/programm/

Среди участников конференции будет много специалистов по интерфейсам со всей России, в том числе Платон Днепровский, Андрей Сикорский и Митя Павлов.

На конференции ожидается чай с плюшками, компьютеры Apple в избытке и свободном доступе и много полезного общения! :)

В перерывах будут розыгрыши призов от компаний-спонсоров и экскурсии в юзабилити-лабораторию 1С.

Конференция бесплатная, но количество мест ограничено, так что спешите! Регистрация доступна на wud2009.ru/reg
Для тех, кто не сможет прийти на конференцию будет онлайн-траснляция докладов.
comments: 2 comments or Leave a comment Add to Memories Tell a Friend

Subject:IT-компании — В поисках структуры: Общие функции
Time:05:58 am
Наткнувшись на форуме SQL.ru на вопрос о том, как спроектировать организационную структуру компании-разработчика ПО, я стал размышлять следующим образом:
  1. Большинство компаний развиваются и растут эволюционно, начиная с небольшой группки энтузиастов-предпринимателей
  2. У большинства компаний структура разная
  3. Организационная структура определяется структурой процессов, набором функций, количеством человек, выполняющих функции, компетенциями и амбициями отдельных участников
  4. Структура процессов определяется рынком, историческими условиями, личными компетенциями отдельных ключевых сотрудников
  5. Набор функций для разных компаний относительно одинаков
Таким образом понятно, что оргструктура — это штука достаточно опосредованно зависимая от многого другого (прежде всего — от исторического наследия), идеальных и оптимальных оргструктур не бывают, бывают лишь более или менее эффективные с разных точек зрения (инвестор, владелец, топ, менеджер среднего звена, заказчик).

Ну что же, давайте начнём с наиболее простого и инвариантного — набора функций.

Они, на первый взгляд, таковы для компаний любого масштаба (3 - 30.000 человек):
  1. Управление компанией
  2. PR, Реклама
  3. Развитие бизнеса
  4. Маркетинг
  5. Финансы
  6. Продажи
  7. Производство
  8. Сопровождение
  9. Кадровый учёт и менеджмент
  10. Бухгалтерия
  11. АХО
  12. Охрана и безопасность
  13. Юридическое обеспечение
Если что-то важное забыл — допишите.

Теперь можно идти дальше и попытаться распределить функции по категориям процессов.
comments: 15 comments or Leave a comment Add to Memories Tell a Friend

Subject:Области знаний об организации деятельности в разработке ПО и около + whoami
Time:11:12 am
Так сложилось, что для многих около-IT-шных людей является новостью, что существуют следующие области знаний относительно организации деятельности в индустрии создания ПО и оказания IT-услуг:

1. BAM: Описание производственной деятельности, модернизация этих описаний, воплощение в практику новых моделей деятельности (Business Analysis, Business Modeling, Business Process Reengineering). Ключевые слова: Workflow, ARIS, BPMS, Р 50.1.028-2001

2. SP: Организация процесса создания ПО (aka Software Engineering, Software Process Management). Ключевые слова: Брукс, CMMI, SWEBOK, RUP, MSF, Agile, XP, ISO 12207

3. PM: Управление (IT)-проектами (Project Management). Ключевые слова: PMBOK, Арчибальд, ДеМарко/Листер, Макконнел, Беркун, MS Project

4. RQDM: Разработка и управление требованиями. Ключевые слова: BABOK, Леффингуэлл, Вигерс, Коберн, Requisite Pro, IEEE 830-1998.

5. SASD: Системный анализ и проектирование ПО (System Analysis & Software Design). Ключевые слова: UML, Буч, Gang of Four.

6. SA: Архитектура ПО (Software Architecture). Ключевые слова: EABOK, Фаулер, IEEE 1471.

7. UID: Проектирование пользовательских интерфейсов (User Interface Design): Ключевые слова: Раскин, Купер, Норман, Константайн.

8. P: Создание ПО (Programming).

9. QAT: Обеспечение качества и тестирование (Quality Assurance & Testing).

10. CM: Конфигурационное управление (Configuration Management). Ключевые слова: CMBOK, VCS.

Дисклеймер №1.
Области знаний (и деятельности) 2 (SP), 3 (PM) и 4 (RQDM) -- это разные области знаний.
Если вы об этом не знаете, то это не значит, что это не так.

Причём 1 (BAM),  2 (SP) и всё остальное -- это три разных уровня работы и детализации.

BAM говорит о том, как организовывать и улучшать деятельность вообще.
SP говорит о том, как организовывать деятельность в разработке ПО.
Остальные 3-10 посвящены отдельным производственным процессам, проистекающим в ходе разработки ПО.

Дисклеймер №2.
Я сознательно специализируюсь на области знаний 4 (RQDM).
Также захожу немного в 1 (BAM), 2 (SP), 5 (SASD) и 7 (UID).
Иногда, совсем редко -- в 3 (PM), 6 (SA) и 9 (QAT).

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

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

comments: 45 comments or Leave a comment Add to Memories Tell a Friend

Subject:8 октября / Семинар Разработка требований и Проектирование интерфейсов
Time:03:23 pm

8 октября в ГУ-ВШЭ на Покровском бульваре, 11 в 8 вечера пройдёт очередная встреча из цикла #uidesignersmeetup, на которой мы попробуем совместить интересы аналитиков и проектировщиков интерфейсов и я расскажу о следующем:

Часть 1 (40 мин)
  • Процесс разработки требований: основные фазы, роли, работы, формы представления результатов по лучшим мировым практикам
  • Бизнес-аналитик / системный аналитик: в чём разница? 
  • Как разработка требований связана с проектированием интерфейсов

Часть 2 (40 мин)
  • Как выстроить эффективную коммуникацию между аналитиком и проектировщиком интерфейса
  • Как строить процесс разработки требований в команде из 5, 15, 25 человек
  • Кто может выполнять роль аналитика, если его нет в команде явно

Обсуждения (Полчаса)

Регистрация

comments: 2 comments or Leave a comment Add to Memories Tell a Friend

Subject:Как организовывать согласование документов
Time:07:45 pm
Увидев вопиющий пример нарушения здравого смысла в посте горе-пма, не удержался, чтобы сформулировать собственные правила процедуры согласования:

1. Участники процесса согласовании должны заранее знать о том, что они будут принимать участие в согласовании.

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

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

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

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

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

7. Большие документы подаются на изучение частями по мере проработки.

8. Чтобы исключить затягивание срока рецензирования, делается очная, если необходимо — многочасовая встреча с совместным проходом по документу.
comments: 83 comments or Leave a comment Add to Memories Tell a Friend

Subject:Проф.опыт. 2000, Отчётно-аналитические системы для ГТК
Time:12:19 am
Чтобы перебить свой обычный критическо-теоретический тон, я решил рассказать о своём профессиональном пути. И мне полезно вспомнить, и у вас контекст для вопросов появится, может ещё и связи кое-какие удастся восстановить.

Итак, 2000-й год. Я на 4-м курсе специальности САПР Бауманки. (Про свои первые попытки подработки в виде рисования электросхем в Автокаде и посещения вербошоу Гербалайфа я так уж и быть, рассказывать не буду). У нас ещё не пошли толком спецпредметы, и из-за военки, на которую я не ходил, образовывалось значительное количество свободного времени.

Мы только что прошли курс по информационному обеспечению САПР, который на практике сводился к теории и практике реляционных баз данных. Один из моих преподавателей и будущий научник по диплому предложил мне подумать о работе с базами данных у своего знакомого. Речь шла о небольшой компании из 5-и человек, которая делала базы данных и приложения для ГТК РФ. Недолго думая, я прошёл короткое собеседование и устроился на полставки.

Офис мы делили вместе с компанией Гроссмейстер на территории института дальней радиосвязи — НИИДАР.

Мои рабочие дни начались с изучения СУБД Oracle 8 через чтение документации и выполнение тестовых заданий оттуда. Позже я занялся программированием и разработкой отчётов в Oracle Developer. Мы писали процедуры обработки данных на PL/SQL, строили формы в Oracle Forms и Oracle Reports. Среда разработки у Oracle Developer достаточно специфическая и с позиционированием и обработкой данных в отчётах возиться приходилось изрядно. Основной темой программ и отчётов были различные данные о таможенных декларациях, налоговых ставках и поступлениях за различные периоды времени.

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

На территории заказчика я впервые столкнулся с политическими играми, типичными для заказчиков государственных. Как оказалось, у ГТК была своя собственная подструктура, ответственная за автоматизацию — так называемый главный научно-информационный вычислительный центр (ГНИВЦ) и, как я понял, мы конкурировали с ними за бюджеты на подряд.

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

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

Под конец работы я уже практически начал нащупывать свою нишу «постановщика задач» для программиста — с одним из парней у нас образовался тандем, где я описывал ему логику работы интерфейса, а он реализовывал задуманное. Также удалось почитать кое-что про хранилища данных, OLAP и многомерные кубы на примере Oracle, что позже весьма пригодилось.
comments: 14 comments or Leave a comment Add to Memories Tell a Friend

Subject:Спиральная динамика от Каптерева, части 3-6
Time:10:11 pm
http://video.yandex.ru/users/tharlo/collection/1/
comments: 2 comments or Leave a comment Add to Memories Tell a Friend

Subject:Алексей Каптерев о Спиральной динамике
Time:06:59 pm
Я ждал выхода этой записи почти год. Этим всё сказано. Спасибо, Петя и товарищи!



comments: 21 comments or Leave a comment Add to Memories Tell a Friend

Subject:Соотношение разработчиков и тестировщиков — Опрос
Time:01:11 am
На прошедшей конференции PM-Labs 2009 был представлен доклад «Компании-разработчики ПО: светлая и темная сторона», в котором Тимур Хайруллин и Юля Нечаева говорили о различиях в подходах к управлению процессами и людьми в продуктовых и аутсорсинговых компаниях. На удивление бурный протест со стороны слушателей вызвал тезис об усредненном соотношении разработчиков к тестировщикам как 5:1.

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

Поучаствуйте в опросе, плс.
comments: 5 comments or Leave a comment Add to Memories Tell a Friend

Subject:Контекстно-ролевые интерфейсы коммуникационных сервисов
Time:03:00 am
Предыстория

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

Когда-то проектировщики интерфейсов этих систем решили основную задачу — (как-то) организовать диалог. Теперь пришло время пойти дальше.

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

На самом деле, есть. Есть такие типичные контексты деятельности и взаимоотношений, как:
  1. Любимые
  2. Друзья
  3. Родственники
  4. Коллеги
  5. Одноклассники/Сокурсники
  6. Знакомые
  7. Знакомства
  8. Сервисы
(Этот список условно приоритезирован по важности, что мы сможем использовать в дальнейшем).

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

Любой собеседник, вступивший с вами в контакт, может быть отнесён к одному или нескольким таким контекстам.

Если сервис знает о приближении дня рождения вашего родственника, он может оповестить об этом вас за неделю и порекомендовать подарок на сумму X, если речь идёт о дне рождения знакомого — оповестить за 3 дня и предложить подарок на сумму X/2.

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

Собственно говоря, корень проблемы в том, что понятия Адресная книга (Список контактов) и Диалоги (Переписка) сейчас сильно оторваны друг от друга по крайней мере в почте (outlook, mail.ru, почта яндекса, gmail) и во многих социальных сетях. Мессенджеры этой проблемой не страдают, т.к. все дискуссии у них организованы ЧЕРЕЗ список конактов. Но проблемы с варьированием поведения у них остаются.

Возможное решение

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

Мир будущего

Видится, что в мире будущего социальная сеть, почта и мессенджер сольются в единое целое.

Резюмируя решения:
  1. Готовые контексты (5-7) как контейнеры, пространства для общения.
  2. Различное поведение сервисов, учиывающее контекст.
См. также:
comments: 17 comments or Leave a comment Add to Memories Tell a Friend

Subject:#WorkshopRequest Нужен тренинг по разработке нефункциональных требований к ПО
Time:02:47 am
Ищу специалиста, который может провести 4-8 часовой тренинг по разработке нефункциональных требований к ПО.

Что ожидается:
  1. Атрибуты качества ПО по ИСО9126.
  2. Вклад атрибутов качества в успех продукта для их разных категорий.
  3. Источники требований к качеству ПО.
  4. Методы выявления требований к качеству ПО.
  5. Способы задания требований к аспектам качества.
  6. Способы проверки сответствия требований к аспектам качества.
  7. Разработка профилей качества для разных категорий продуктов / видов релизов.
comments: 24 comments or Leave a comment Add to Memories Tell a Friend

Subject:Кто во что горазд
Time:07:50 am
Иногда мне задают вопросы про разные задачи и про людей.
Вообще сейчас кризис и люди, которые умеют решать задачи, нужны.
Так вот я решил поделиться тем, что знаю.
Заодно некоторые люди узнают, чем же они занимаются %)
Ну и себе памятку составить.
Если кто против своего упоминания — черкните мне, вынесу.
Если хотите что-то уточнить или вписаться — тоже пишите, но учтите,
что я пишу только про тех, кого знаю и в качестве работы кого я не сомневаюсь.

Визионерство

[info]ailev , [info]urbansheep 

Анализ рынка
[info]oddboy , [info]justdoitbaby 

Определение продукта
[info]lavale , [info]afriki , [info]milaya_o , [info]patamyshta 

Продажи

[info]ideali 

Реклама
[info]_subtle_ , [info]soulskeeper 

PR
[info]klemka

Разработка требований

[info]aivanova , [info]alextheraven , [info]bas4all , [info]make_summer 

Управление проектами
[info]blanditiae , [info]gastarblogger , [info]dastilda , [info]milaya_o , [info]cornerles , [info]ay5 

Проектирование интерфейсов
[info]eril , [info]jvetrau 

Клиентсайд-разработка
[info]quappa , [info]dixi 

Вёрстка
[info]tachisis

Проектирование и разработка архитектуры
[info]ivbeg , [info]raa , [info]tobe , [info]agreb 

Руководство командой разработчиков

[info]tobe , [info]raa , [info]agreb 

Фасилитация
[info]ideali , [info]allileja 

Постановка процессов обеспечения качества
[info]slavapankratov , [info]atermath , [info]ivbeg 

Постановка процессов разработки
[info]cartmendum , [info]zibsun 

Тексты
[info]urbansheep , [info]ay5 

Администрирование систем
[info]rdesperado 

Организация технической поддержки
[info]meatreach 

Документация пользователя
[info]akeepaki , [info]orie , [info]nat_crow 

Организация оффлайн-движухи (aka Event Management)
[info]_lothar_ , [info]nikolaj , [info]lost_in_net , [info]allileja , [info]beejess 

Журналистика
[info]an_chous , [info]lorbit 
comments: 40 comments or Leave a comment Add to Memories Tell a Friend

Subject:Учебные проекты
Time:12:33 am
Очередное предложение для разноображивания жизни.

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

Другой вариант — вы делаете некоммерческий проект, тему которого выдвигаю я.

Сейчас у меня есть на выбор следующие эрудиция и эстампы:
1. Развитие сайта UML2.ru
2. Веб-сервис управления задачами
3. http://beskov.ru/2006/04/17/region-site-concept-basics/

Свои заявки присылайте на systemdesigncoach @ beskov.ru

Если у вас есть продукт, то опишите его в форме:
1. Кто является пользователем
2. Какую его проблему решаем
3. Каким образом
4. Чем это лучше того, что есть сейчас
5. Кто и за что платит
comments: 13 comments or Leave a comment Add to Memories Tell a Friend

Subject:Конференция Remix — Что говорят люди?
Time:12:53 am
Как вы знаете, завтра (уже сегодня) в мск проходит конференция по веб-разработке REMIX.

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

Как узнать, что пишут о конференции?
Зайдите на twihoo.com/remix и знакомьтесь с отзывами в реальном времени:

image


Как сообщить своё мнение миру?

Запостите сообщение в twitter с хеш-тегом #remixru и в течении нескольких минут оно появится по ссылке выше. Кроме того, вы всегда сможете вернуться и ознакомиться с отзывами о прошедшем событии.

Как задать вопрос организаторам REMIX?
Напишите в twitter пользователю @remixru

Enjoy!
comments: Leave a comment Add to Memories Tell a Friend

Subject:Вопросы для собеседования: (Визуальное) моделирование
Time:11:44 am
Придумал вопрос —  Перечислите виды визуальных моделей систем, которые вы знаете в порядке убывания их полезности и поясните выбранный порядок.
comments: 51 comments or Leave a comment Add to Memories Tell a Friend

Subject:Темы UX-семинаров
Time:08:47 pm
 Что мне интересно:

Профессия
  • Профиль профессии UX-аналитика и проектировщика: знания и умения
  • Критерии и показатели эффективности работы UX-специалиста
  • Как должна быть построена програма обучения специалиста и почему
Рынок
  • Как эффективно продавать себя как UX-специалиста
  • Обзор рынка UX в России и сравнение с мировым
Процессы
  • Интеграция UX и SE (Software Engineering)-процессов
  • Особенности организации UX-процесса для разных категорий продуктов
  • Принципы и методы кастомизации UX-процесса под проект
  • Организация командной работы UX-специалистов
Аудит продукта
  • Изучение паттернов использования продуктов: недорогие технические средства мониторинга пользовательской активности для веб-систем
  • Организация комплексного юзабилити-аудита продукта
  • Связь бизнес-показателей и пользовательских качеств продукта для разных их категорий
Задачи по этапам
  • Обзор методов изучения аудитории продуктов от простых к сложным
  • Сравнение и особенности описания взаимодействия пользователя через User Story, Use Case и Scenario
  • Взаимосвязь концепции продукта и концепции интерфейса
  • Примеры создания разных концепций интерфейсов разными командами для одной задачи (конкурс?)
  • Типовые решения типовых задач: регистрация, авторизация, почтовые оповещения, интерактивные оповещения, переписка, журнал событий, списки контактов, фильтры, тэги, календарь событий
Спецтемы
  • Разработка полноценной системы навигации через клавиатуру и горячие клавиши
  • Принципы и примеры построения расширяемого интерфейса
  • Особенности проектирования взаимодействия для мобильных устройств
  • Проектирование социального взаимодействия в сообществах
Что я могу попробовать рассказать:
  • Обзор рынка UX в России и сравнение с мировым
  • Обзор методов изучения аудитории продуктов от простых к сложным
  • Сравнение и особенности описания взаимодействия пользователя через User Story, Use Case и Scenario
  • Взаимосвязь концепции продукта и концепции интерфейса
  • Связь бизнес-показателей и пользовательских качеств продукта для разных их категорий
comments: 6 comments or Leave a comment Add to Memories Tell a Friend

Subject:Минимальный сценарий разработки ТЗ и 10 часов работы
Time:12:10 am
Деятельность по созданию ТЗ состоит из 3-х важных фаз, выполняемых итерационно:
  1. Выявление требований
  2. Документирование требований
  3. Согласование требований
Поскольку на грабли продолжаем наступать, описываю минимальный сценарий разработки ТЗ:
  1. Заказчик рассказывает Аналитику своё представление о продукте, Аналитик задаёт необходимые вопросы и получает ответы.
  2. Аналитик пишет 1-ю версию требований.
  3. Аналитик обсуждает 1-ю версию требований с Разработчиком на предмет принципиальной реализуемости, вносит правки, получает версию 2.
  4. Аналитик обсуждает версию 2 требований с Заказчиком на предмет соответствия его интересам и представлениям, задаёт вопросы, получает фидбек.
  5. Аналитик создаёт версию 3 на основании фидбека и согласует её у Заказчика с правками до 4-й версии.
  6. Аналитик обсуждает версию 4 с Разработчиком и закрывает все вопросы последнего, получая версию 5.
Итого — для самого малого проекта нужно: МИНИМУМ 5 версий документа, 3 сессии работы с Заказчиком, 2 сессии работы с Разработчиком.

Для самого малого проекта, ЕСЛИ ВСЁ ИДЁТ ГЛАДКО:
  • 5 версий — это 5 часов документирования требований (по часу на версию).
  • 5 сессий  общения — 5 часов выявления и согласования требований (по часу на сессию).

Таким образом самый малый проект тянет на 10 часов работы по требованиям. (Но это затраты, которые практически всегда окупаются).
comments: 40 comments or Leave a comment Add to Memories Tell a Friend

Subject:Контакты навсегда
Time:03:57 pm
Если я тебе зачем-то нужен:

Добавь меня в МК и узнай мой номер телефона, имейл, Skype, Gtalk и всегда имей доступ к актуальным данным.

comments: 4 comments or Leave a comment Add to Memories Tell a Friend

Subject:Usability Headhunter.ru
Time:03:21 pm
С удовольствием послушал Вировца месяц назад, очень полезно и конструктивно было. Верю, что с точки зрения бизнеса было эффективно и правильно строить развитие продукта, опираясь на отзывы сейлов, продающих корпоративные пакеты.

Но. Сейчас (за последние годы) аудитория кандидатов сильно сместилась от менеджмента в сторону специалистов.

Сегодня наблюдал, как тётя заполняет анкету на HH.ru, задавая мне вопросы почти по каждому полю, попадая в тупики и т.д.

И возникают вопросы к ребятам, которые делали его интерфейсы — а каким таким usability вы на проекте занимались, какие проблемы решали, что решили, а что — нет и почему?
comments: 12 comments or Leave a comment Add to Memories Tell a Friend

Advertisement

[icon] Системный анализ в Разработке ПО и Другие
View:Recent Entries.
View:Archive.
View:Friends.
View:User Info.
View:Website (Профиль в Моём Круге).
View:Блог избранного на beskov.ru. UML 2 • RU.
Любимые ЖЖ-сообщества:Бизнес- и системный анализ. Системные архитекторы. User-centered Design. Управление проектами. Web 2.0.
You're looking at the latest 20 entries.
Missed some entries? Then simply jump back 20 entries