Введение
Данный пост написан в выполнение домашнего задания по четвёртой главе курса Моделирование и Собранность. Пост резюмирует результаты работы в паре по рассмотрению объектов с неплотным концептуальным пространством из учебного задания. Благодарю Александра Тимченко за время, уделённое мышлению проговариванием.
Предложения по итогам обсуждения
Программисты vs. биостатистики
Данные понятия часто смешиваются внешними клиентами, что приводит к неэффективному использованию ресурсов (более редкий ресурс времени биостатистиков прописывается как обязательный в регламентах внешних клиентов в тех случаях, когда было бы достаточно предоставления более доступного ресурса времени программистов).
Предлагается: ввести понятие “специалист по анализу данных” в виде надкласса над как программистами, так и биостатистиками. Прописать в регламентах внешних клиентов использование ресурсов данного надкласса, что позволит лучшее оперативное распределение ресурсов.
Данные
Понимаются по-разному ролями в зависимости от вовлечённости в работу с этими данными. Например, дата-менеджеры, не контролирующие сбор данных внешних вендоров, могут не понимать, что данные могут быть также и у этих вендоров.
Поскольку реальные негативные последствия от этой концептуальной неплотности возникают редко, предлагается не менять, т.к. интереса у описанной в задании роли тут нет.
Дедлайны
Из-за понятных эгоистических предпочтений, даты дедлайнов понимаются в зависимости от того, является ли роль получателем или производителем рабочего продукта. Например, если роль подготавливает данные, то её исполнитель будет интерпретировать 4 октября как дату, к вечеру которой данные должны быть предоставлены. Получатель же этих данных будет считать, что дедлайн данные должны быть готовы к утру 4 октября и их можно будет взять в работу.
Предложение: ввести понятие “майлстоун” (или “веха”), например “подготовка данных” и документировать дедлайны только в связке с майлстоунами. Таким образом, составное понятие “дедлайн подготовки данных” будет явно пониматься, как конечная дата для окончания работ по предоставлению данных, а никак не начальная дата по их дальнейшему анализу, для которой всегда будет свой, отдельный дедлайн. Такая связка должна применяться во всех рабочих продуктах планирования, например - плане проекта.