Size: a a a

Архитектура ИТ-решений

2020 August 06

DK

Daria Kaftan in Архитектура ИТ-решений
Олег Игонин
Вы про сладкое, а я про тёплое. Если ваш разработчик/тестировщик/архитектор/пм не поймёт что и зачем надо сделать, то риски будут намного выше.
А мне всё надо 😉
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Сперва ориентируетесь на людей, надо что-то добавить - добавляете, но как - это уже другой вопрос.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Можно делить ТЗ и ОПЗ
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Можно для каждого человека оформлять сноски. Можно разираться брифингами.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Daria Kaftan
А мне всё надо 😉
Самый главная задача - это формирования в рамках проекта общего настроя, когда люди понимают цели проекта, понимают шаги его достижения, достаточно подробно понимают как он должен работать. Обычно это работа пм"а сформировать правильную последовательность работ, освободить команду от прочей нагрузки, сконцентрировать процесс. Но они этого не умают. Я ни одного не видел. Хотя, может один и был...

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

ОИ

Олег Игонин... in Архитектура ИТ-решений
И "стягиваете" людей брифингами, общением с заказчиком, консультациями, общими чатами, летучками.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Но если у вас есть коллега/и, который/ые пришли тут работу работать, то всё это бесполезно. Им надо отработать на 3 и пойти домой. И для таких есть свой подход.
Для заинтересованных - свой.
Для учёных, систематизаторов, испытателей - свой.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Простой пример. Если у вас разработчик - дятел, то фигачте подробные требования для тестирования, а разработчику оставьте его велосипед.
источник

ОИ

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

ОИ

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

ОИ

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

ОИ

Олег Игонин... in Архитектура ИТ-решений
ВСЯ разработка - это про людей и их желания на самом деле. Всё остальное - инструмент.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Стандартная тема: "Сделать сэндвич с вареньем и арахисовым маслом"

https://youtu.be/7fJ42lfCUXg?t=782
YouTube
2. CS50 на русском: Лекция #2 [Гарвард, Основы программирования, осень 2015 год]
Доп. материалы и задачи к лекции - https://javarush.ru/s/level_0
Весь курс CS50 — https://javarush.ru/s/course_cs50


//Перезалили 2-ю лекцию. Теперь ее можно смотреть с мобильных устройств.

Краткое описание второй лекции (Week 0, continued):

В этот раз @David Malan и его помощники отправились в (не такой уж) далекий Коннектикут, в Йельский университет.

Студенты этого представителя «Лиги плюща» с энтузиазмом приняли гарвардскую команду, и узнали много нового из лекции, а именно:

• Что такое алгоритмы. Казалось бы, такое простое понятие, но на самом деле алгоритмизовать даже столь элементарный процесс, как намазывание арахисового масла на тост совсем не просто. Ребята вам это покажут на практике=).

• Как эффективно посчитать количество людей в аудитории? У нас есть такой алгоритм.




• Есть такое английское выражение “From Scratch”. Переводится оно как «С самого начала». Но можно также перевести как «Начиная со Scratch», если слово Scratch понимать как специальный учебный язык программирования. Так вот…
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
По хорошему, надо быть на одной волне.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Олег, а вам встречались какие-то методики? Вы мне рассказываете очень общие концепции, и это тоже неплохо, но такой опыт у меня имеется и выводы схожие, а вот систематизированного опыта, оформленного в методики - не хватает.
источник

F

Fagor in Архитектура ИТ-решений
Alexander Teterkin
Не только подтверждение работ. Как на счет фиксации намерений? Как на счет общего понимания задач? В одном из исследований показали, что 60% всех проблем с ПО вызвано некорректным пониманием требований. Как быть если требования не зафиксированы?
Сбор требований и после их фиксация. Намерение это работа этапа инициации.
источник

F

Fagor in Архитектура ИТ-решений
Daria Kaftan
Состав отчетной документации - да. А остальное - как получится. Тем более помимо перечня этих доков нужно подбирать инструменты. РП не занимается подбором инструментов для каждой практики. Для автогенерации доков, для организации тесткейсов, для управления требованиями. Этим занимаются лиды направлений. Менеджер по качеству, тимлид, и т.д.
Да, он согласует выходные данные сервисов. И объем работ отражающийся в них. Этотего ресурсы. Если аутсорс, может да, вы выставляете ценц человека с учетом всех инструментов. А если нет?
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Daria Kaftan
Олег, а вам встречались какие-то методики? Вы мне рассказываете очень общие концепции, и это тоже неплохо, но такой опыт у меня имеется и выводы схожие, а вот систематизированного опыта, оформленного в методики - не хватает.
Я думаю, что о том, как сформировать команду как единый рабочий механизм, написано уже много книг. Просто мы каждый раз пытаемся сделать велосипед, не можем нормально запланировать работы и внутренне не согласны с планируемыми сроками.

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

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

Может быть коллеги помогут или подскажут.
источник

F

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

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

ОИ

Олег Игонин... in Архитектура ИТ-решений
Fagor
+, правильно говорите это работа ПМа. Если он договаривается с Архитектором что в проекте не нужен арчимейт, значит он не нужен.
Проджекты и архимейт - это вроде разные вселенные. Продукт зачастую тоже не может заставить использовать AM, т.к. если его не знают аналитики/разработка, то сразу нет.
источник