Category: it

Category was added automatically. Read all entries about "it".

alexander pavlyut

Только трансперенси во всех отношениях.

Недавно смотрел интересный видос про брендинг (https://www.youtube.com/watch?v=9Jt5a6V_fyM) и там была затронута очень хорошая мысль по поводу прозрачности в организациях - мол в паблик все вещают что да да, мы за прозрачность, мы супер прозрачны, а по факту получается всегда мутная вода.

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

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

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

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

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

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

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

Это все те люди которые не знают что такое TDD -> RED Сначала обязательный фейл -> разбор результатов -> повторо попытки и GREEN !!

Ну не будем об этом я про другое сейчас.

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

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

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

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

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

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

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

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

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

И если помыслы чисты - у нас не будет проблем.

Если же я что-то увижу или не получу ответ на вопрос - я всегда задам этот вопрос.

Только так создаются великолепные интернет-проекты.

http://www.deppkind.com/devprocess
alexander pavlyut

У нас же есть техническое задание на систему / сайт / приложение / проект ...

Ситуация

  1. На входе в студию клиент (виртуально / реально не важно).

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

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

  4. Ждет.

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

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

Соглашение о терминологии


  1. Артефакт - физическое представление в реальном мире чего либо сотворенного человеком.

  2. Замысел - то что находится в голове или головах клиентов.

  3. Пожелания - артефакт замысла.

  4. Требования - согласованные с реальностью пожелания.

  5. Физика окружения - в случае с сайтом это все компоненты из которых он может быть изготовлен согласно консорциому w3c. В случае с мобильным приложением - это apple developer program или andriod development и тд

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

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

Мухи отдельно - котлеты отдельно.

Рассмотрим очень коротенько жизненный цикл любого замысла и его реализации в реальность:


  1. Замысел (что) -> хотелось бы вина

  2. Пожелания (сформулировано зафиксировано) -> не послать ли нам гонца за бутылочкой винца

  3. Требования (контрольная точка) -> красное сухое французское

  4. Архитектурное решение -> будем потреблять дома из бутылок а не в розлив из бочки в ресторане.

  5. Техническое задание -> в магазине номер 5, выкупить 2 бутылки французского за 5 рублей каждую.

  6. Сооружение (производство, выполнение) -> сходили купили привезли показываем

  7. Получение (верификация) -> приняли по требованию, детали сверили с тз по необходимости.

  8. Ввод в эксплуатацию -> открываем бутылки

  9. Эксплуатация -> разливаем по бокалам, потребляем блага.

Еще раз с сайтом или мобильным приложением:


  1. Замысел (что) -> хотелось супер сервис который может делать дело

  2. Пожелания (сформулировано зафиксировано) -> нам нужен сервис который делает это дело X, Y, Z

  3. Требования (контрольная точка) -> сервис должен делать X, Y, а Z не возможно при наличие X и Y, давайте лучше H.  ОК.

  4. Архитектурное решение -> X мы сделаем как страницу. Y будет как игра, а H будет как запрос через форму.

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

  6. Сооружение (производство, выполнение) -> кодинг, сборка, тестирование по тз, прогон сценариев.

  7. Получение (верификация) -> деплоймент (развертывание в эксплуатационное окружение, appstore, amazon ...)

  8. Ввод в эксплуатацию -> принята работа, пошли баннеры реклама, регистрации.

  9. Эксплуатация -> сервис работает, конверсии растут, кеш заходит в кассу.


Кто кому что должен?

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

Для наглядности я изложил одному из клиентов схемку жизненного цикла одного(!) требования и по сей день показываю для ответа на вопрос что делать:






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

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

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

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


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

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

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

Вот простые правила предъявляемые мною к любому техническому заданию:

Требования к техническому заданию


  1. Техзадание должно быть

  2. Оно пишется исполнителем в противовес на согласованные требования и подписывается сторонами.

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

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

    • как при этом он будет выглядеть

    • каково его назначение в рамках всей системы

    • как будет обслуживаться данный элемент в процессе эксплуатации и кем

    • и тд.


  4. Содержит критерии приемки результата - что именно в рамках физики системы дает ясное понимание что конкретный элемент или сценарий системы работает корректно и успешно.

  5. Написано в паре со специалистом (с подтверждаемой квалификацией) в области системной инженерии требований и специалистом по проектированию взаимодействию с системой.

О требованиях

Требования - это описание (модель) системы к которому сбоку мы приписываем деонтическую модальность. (Анатолий Левенчук)

Отдельно стоит отметить что Бизнес требования - это тербования к тому как должна протекать деятельность системы.

Требования отличаются от пожеланий по простому принципу: требование = пожелание + обоснование.

Для того чтобы обосновать требование необходимо предоставить артефакты подтверждений что требования определены реальной потребностью и своим выполнением перекроют (согласуется с) миссию всего проекта (
http://deppkind.livejournal.com/1863.html)

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

| 1. требование | 2. для чего нужно |  3. возможное решение |

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

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

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

Примеры требований из реальных проектов:



  1. Каталог должен показывать (в глаза) товары

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

  3. SMS о тренировках должны приходить на телефоны (устройства) - чтобы не звонить каждому.

  4. Страница товара должна передавать конкретную информацию x y z (в глаза) - для принятия решения о ...

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

Если какое-то пожелание из видения решения становиться крайне важным - оно перекачивает в раздел документа под названием "Ограничения на решение".

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

Все это позволяет синхронизировать онтологию мира клиента и нашу для более ясного взаимопонимания.

Когда у нас есть требования - дальше все отрабатывается на автомате - процесс просто выполняется. Тут уже дело техники - за хорошим исполнителем как правило не заржавеет.

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


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

Трассировка требований - это инструмент, позволяющий показать степень проработки и влияния требования на компоненты системы.

В этот момент можно понять степень влияния требований.
Требования поменялись - конфигурация поменялась - еще и указывает трассировку и степень влияния.

Требования подписываются сторонами. Требования легко меняются и дополняются постоянно в процессе работы, это фиксируется и не мешает работе. Требования пишутся клиентом - согласуются исполнителем, подписываются сторонами.

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

Чуть подробнее на поиск решения через Job Stories я писал тут http://deppkind.livejournal.com/3259.html.

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

Назначение документа-требований - проработка пожеланий и контроль результата.

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

Где брать требования?


  1. Сесть и писать - ничего в этом сложного вообще нет. Требования это ваши же ожидания.

  2. Если совсем сложно - требования можно заказать, кто сколько берет за это (это интервьюирование вас, где и как это делать каждый решает сам - я делаю это только в студии и за деньги), тут помесь работы секретаря + машинистки. Ну и контрольные вопросы конечно же от нас )

  3. На собранные требования можно давать решения - а только на каждое решение может быть уже цена и сроки. Можно за 5 рублей а можно и за 50 лямов. Тут кто что вам предложит на рынке, каковы ваши потребности и ситуация.

  4. Ждать и требовать подробнейшее тз от исполнителя.

  5. Только после четкого понимания пускать в сооружение (разработку) систему.

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

Вопросы, комментарии приветствуются.

Найденные опечатки исправляются, добавляются новые.