Вообще, ответ K_Chicago выглядит правдоподобно. Сейчас попробую объяснить, почему так.
Классическая схема полного цикла действий, когда нужно сделать хорошо и чтобы кнопочка красная выглядит следующим образом:
Определить всех заинтересованных лиц и их роль в принятии решений (т.к. людей много, работаем с их классами)
Собираем с них требования
Проверяем требования на полноту (очевидные самоподразумевающиеся требования вроде работы без электричества) и непротиворечивость (отсутствие разных интересов)
При наличии противоречий (т.е. всегда) собираем совещание и доводим людей до разрешения противоречий
При неполноте требований (т.е. всегда) идём к основным заказчикам и пугаем их цифрами про стоимость SLA в 98%, 99.5, 99.9, 99.99 и т.д., определяя какие именно НФТ к продукту у них
Собираем всё это в единый документ (итоги совещания, концепция доработки, BRQ List, whatever) и докапываемся до всех с просьбой вдумчиво прочитать и согласовать, обозначив сроки автопринятия документа (т.к. читать всё равно не будут)
Идём к архитектору/проджекту/лиду/случайному разработчику и просим на основании этого документа дать оценки: возможно ли это сделать в принципе (очевидные вещи надо было ещё на этапе совещания отсечь ибо стыдно), как можно сделать это проще, быстрее и дешевле и чем именно для этого нужно пожертвовать
Учитывая ограничения системы, интеграций, регламентов и прочего - создаём документ для разработки с описанием системы и предполагаемой архитектурой, полученной на предыдущем этапе
Собираем разработчиков, проводим демо требований, оперативно заносим всю критику и исправления в документ, просим их примерно оценить сроки работы
Возвращаемся к заказчиком с оценкой, наблюдаем никогда не надоедающую сцену "Я думал тут работы на час, всего кнопочку добавить", проводим раунд торгов по требованиям и определяем MVP с приоритетами
Радуем разработчиков, что вместо велосипеда с турбореактивным двигателем достаточно велосипеда с двс о семи колёсах, расписываем требования для разработчиков
Мужественно отвечаем на возникшие вопросы
Как оно выглядит со стороны:
1, 3, 12 - пить кофе и заниматься произвольными делами
2, 5, 7, 10 - отвлекать занятых людей глупыми вопросами
Меня немножко потряхивает уже от слова "проект". Я сейчас заканчиваю первый семестр магистратуры в немецком ВУЗе и именно проекты были самым главным его кошмаром. У нас был 1 проект на 1 неделю, на команду до 3 человек, проекты в течении семестра были по трём направлениям: Data Science, Complex Systems, Advanced Algorithms in Bioinformatics. Расчёты в gitlab + оформление отчёта в Latex.
Хотя я и должна признать, что благодаря этим 14 проектам я получила общее представление о дальнейшей учёбе и определилась с будущим направлением (Major — Advanced Algorithms, Minor — Data Science), нагрузка была катастрофической. А впереди ещё защита одного из проектов по выбору в виде Scientific Poster.
Да, про 10 часов всё верно.
Если пришел в 10 утра, то раньше 8 вечера не уходишь. Насколько жестко это соблюдается зависит от начальников. У каждого их несколько.
И вишенка на торте: ежедневно надо расписать куда ты потратил эти 10 часов. Указать конкретные задачи(часть автоматиом списывается по трекингу).
Да, слово вполне верно переводится. У нас и у них аналогично бывает, что «приятелем» называют и тех, кто приятен и просто пользуют в виде неофициального обращения: «Эй приятель, убери-ка свою тачилу с дороги, а то выехать не могу.»
Вообще, ответ K_Chicago выглядит правдоподобно. Сейчас попробую объяснить, почему так.
Классическая схема полного цикла действий, когда нужно сделать хорошо и чтобы кнопочка красная выглядит следующим образом:
Определить всех заинтересованных лиц и их роль в принятии решений (т.к. людей много, работаем с их классами)
Собираем с них требования
Проверяем требования на полноту (очевидные самоподразумевающиеся требования вроде работы без электричества) и непротиворечивость (отсутствие разных интересов)
При наличии противоречий (т.е. всегда) собираем совещание и доводим людей до разрешения противоречий
При неполноте требований (т.е. всегда) идём к основным заказчикам и пугаем их цифрами про стоимость SLA в 98%, 99.5, 99.9, 99.99 и т.д., определяя какие именно НФТ к продукту у них
Собираем всё это в единый документ (итоги совещания, концепция доработки, BRQ List, whatever) и докапываемся до всех с просьбой вдумчиво прочитать и согласовать, обозначив сроки автопринятия документа (т.к. читать всё равно не будут)
Идём к архитектору/проджекту/лиду/случайному разработчику и просим на основании этого документа дать оценки: возможно ли это сделать в принципе (очевидные вещи надо было ещё на этапе совещания отсечь ибо стыдно), как можно сделать это проще, быстрее и дешевле и чем именно для этого нужно пожертвовать
Учитывая ограничения системы, интеграций, регламентов и прочего - создаём документ для разработки с описанием системы и предполагаемой архитектурой, полученной на предыдущем этапе
Собираем разработчиков, проводим демо требований, оперативно заносим всю критику и исправления в документ, просим их примерно оценить сроки работы
Возвращаемся к заказчиком с оценкой, наблюдаем никогда не надоедающую сцену "Я думал тут работы на час, всего кнопочку добавить", проводим раунд торгов по требованиям и определяем MVP с приоритетами
Радуем разработчиков, что вместо велосипеда с турбореактивным двигателем достаточно велосипеда с двс о семи колёсах, расписываем требования для разработчиков
Мужественно отвечаем на возникшие вопросы
Как оно выглядит со стороны:
1, 3, 12 - пить кофе и заниматься произвольными делами
2, 5, 7, 10 - отвлекать занятых людей глупыми вопросами
4, 9 - собрать совещание, лишь бы не работать
6, 8, 11 - написать документ по итогам встречи
? - работать
Меня немножко потряхивает уже от слова "проект". Я сейчас заканчиваю первый семестр магистратуры в немецком ВУЗе и именно проекты были самым главным его кошмаром. У нас был 1 проект на 1 неделю, на команду до 3 человек, проекты в течении семестра были по трём направлениям: Data Science, Complex Systems, Advanced Algorithms in Bioinformatics. Расчёты в gitlab + оформление отчёта в Latex.
Хотя я и должна признать, что благодаря этим 14 проектам я получила общее представление о дальнейшей учёбе и определилась с будущим направлением (Major — Advanced Algorithms, Minor — Data Science), нагрузка была катастрофической. А впереди ещё защита одного из проектов по выбору в виде Scientific Poster.
Если пришел в 10 утра, то раньше 8 вечера не уходишь. Насколько жестко это соблюдается зависит от начальников. У каждого их несколько.
И вишенка на торте: ежедневно надо расписать куда ты потратил эти 10 часов. Указать конкретные задачи(часть автоматиом списывается по трекингу).