Выявление скрытых работ
Есть скрытые работы, которые не было видно заранее, поэтому их нет в списках.
А есть ad-hoc (поручения?), которые прилетели прямо сейчас. Их тоже нет в списках, потому что их и не планировалось. Или всё-таки планировалось?
Например, ответы на вопросы по предыдущим РП. Онии должны быть предусмотрены, но на них не всегда запланировано время. Почему - по каждому РП всего не напалнируешь?
Это проблема планирования или исполнения?
Планирование в мелочах исходит из того, что на выходе идет “качественный” РП.
На большом масштабе учитываем повторы, но скорее один, не больше. Циклы для каждого РП учитывать сложно. Что делать с этим?
Что делать с этим в моменте?
- Записать задачу, чтобы вынести из головы.
Куда записать? Нужен дневной список задач, попробую вести в coda - Планируем время в дне для ответа на такие вопросы
- В рабочее время отключаем каналы связи? С этим сложно, мессенджеры являются и каналом свзяи для выполнения текущих задач.
Пробую в течении минимум недели обращать внимание, записывать все входящие поручения/вопросы.
НИ НА ЧТО НЕ ОТВЕЧАТЬ СРАЗУ, ЕСЛИ ЭТО БОЛЬШЕ 5 МИНУТ
Ситуация с планированием
Заранее запланированы некоторые работы и их последовавтельность.
Но по разным причинам на входе каких-то работ получачются не достаточно готовые РП.
Возможные причины:
-
Недостаточно качественное (с точки зрения след. этапа) выполнение предыдущих работ по формированию РП
-
новые обстоятельства, не учтенные на этапе планирования
-
требования новых РП
-
изменилась нужная полнота/состав отдельного РП
В итоге получаются разные оценки для задач - если выполнять “в один присест” с готовыми входными РП или отвлекаться по этой задаче для получения и уточнения РП.
При планировании как правило считается срок выполнения для ситуации “если всё хорошо”. Но так случается редко.
Поиск инструментов
Когда люди ищут “формат арх. документа”, “формат диаграмм”, “инструмент для диаграмм” - они на самом деле чаще всего ищут метод, через объекты внимания метода. Определить - что важно? А с инструментами для диаграмм - еще и метод непосредственно работы руками с этими диаграммами.
При этом большие фреймворки типа TOGAF, ArchiMate говорят - вот целая россыпь объектов, выберите, что из этого вам нужно. Для такого выбора тоже надо иметь определенные знания.
Ровно так же, когда в проекте хотят “внедрить BPM” (Business Process Management) систему или любое другое крупное коробочное решение, от него ожидают методологию, как работать с процессами, как их строить, разные Best Practice. У нас на проекте была ситуация, когда мы делали решение на базе софта очень крупного иностранного вендора и заказчику не очень нравилось, как выстроено наше решение, но конкретных проблем он указать не мог. Был привлечен сотрудник вендора (архитектор из европейского офиса) для аудита. Итог аудита - коллеги сделали всё правильно с точки зрения техники и паттернов проектирования. Но не слова про методологию построения процессов, которую никто и не обещал исходно. Т.е. при продаже конечно говорятся всякие общие слова про best proctices, но в реальности это не всегда присутствует вместе с продуктом.
Когда мы на работе рассуждаем - давай так сделаем, нет давай так - мы как правило обсуждаем выбор практик или методов из существующих. Т.е. компонуем(?) на лету методологию.