Методология предполагает требования к описанию функций и требований к проекту, SCRUM например, к стори, иными словами формализацию бизнес-требований, в KANBAN к описанию тасков. Стандарты управления проектами также формализуют всё, что касается коммуникации в проекте. Следуя этим требованиям и стандартам, как показывается практика, легко получить предсказуемый результат.
Понятно, спасибо за ответ. В крупных компаниях существуют корпоративные стандарты интервьюирования заказчиков, иногда даже утилиты пишут специальные, которые позволяют формализовать бизнес-требования. Сталкивались ли вы с такими стандартами, на сколько, по вашему они отличаются от метамодели, которую вы предложили? Можно ли вашу метамодель привязать к созданию story в SCRUM?
Мне кажется, что вы как-то узко понимаете интеллект. Называя не физический труд не интеллектуальным и сильно примитивизируете (утрируете) описывая профессии и процессы о которых мы говорим. Безусловно эти люди не ученые, и не творческая интеллигенция, но для эффективного выполнения обязанностей им нужно как минимум быть опытными пользователями ПК, разбираться на уровне пользователя в работе операционных систем с которыми работает их оборудование, освоить ПО, которое они применяют — это требует как минимум базового понимания работы устройств обработки данных. Но это всё в теории, на самом деле всё сложнее. Например, чем сложнее авто и чем выше технологический уровень систем в них заложенных, тем больше знаний (в том числе и теоретических) должно быть у автослесаря для того, чтобы произвести ремонт, особенно если он ремонтирует. Не спорю, ряд процессов упростился до правильной замены деталей или юблоков, но другие усложнились. Например даже подключение некоторых диагностических систем требует понимания работы интерфейсов. В авто появилось много электроники, что требует от работников сервиса значительных знаний о работе и ремонте таких систем. Ваш тезис о том, что не нужно думать мне понятен. Но это в теории, на практике думать нужно. Технологическое развитие пока не привело нас к тому моменту, когда оно будет угрожать нам видовой деградацией. Возможно, безусловно я обманываюсь и хочу слишком хорошо думать о людях. Более того, мы живём в мире очень доступной информации. И большинство сведений доступны. Люди могут повышать интеллектуальный уровень практически без ограничений, популярность многочисленных курсов — свидетельство интереса к знаниям. Понятно, что это не академическое образование, но списывать со счетов это не следует.
Если конкретно, то Начиная от кассира, которому порой нужно самостоятельно восстанавливать соединение от терминала до управляющего устройства, которое отправляет транзакцию, заканчивая автослесарем, который без навык компьютерной диагностики не сможет нормально заработать. Я не говорю о всестороннем интеллектуальном развитии, эрудиции, невербальном интеллекте и эмоциональном интеллекте и т.д. Нет — в этом плане всё плохо как раз.
Я говорю о том, что физического труда стало меньше, интеллектуального больше.
? Поясните. Для меня лемминги это грызуны преимущественно обитающие в северных широтах и прогрызающие практически всё. Коих раньше ошибочно считали животными-суицидалами. А вы о ком? Хотите написать хомяки — так и пишите.
«Какие именно массовые занятия интеллектуально усложнились, не подскажете?» подавляющее большинство. Компьютеризация призванная облегчить ряд процессов с другой стороны стимулировала человечество к освоению не свойственных ранее навыков, предрасположенность к освоению которых не была заложена генетически, что привело к появлению принципиально новых нейронных связей. Каким бы примитивным вам(в силу возраста, о котором вы упомянули) не казалось будущее поколение, оно неизбежно будет сложнее предыдущего, на уровне нейробиологии. Будущее, вероятнее всего, за исчезновением примитивного физического труда и автоматизацией массового производства. Это гарантированно изменит представление о человеческом труде, уже изменило, и все социальные аспекты с ним связанные, социальные лифты, распределение благ и т.д.
Мне думается, что вы излишне радикально смотрите на проблему и при этом слишком критично относитесь к людям. Корректным назвать сравнение с грызунами также не могу. Сорри. Понятно, что в внушительная часть человечества несколько обделена интеллектом, но такое положение вещей существовало на всём протяжении существования нашего вида. Более того, количественно (не берусь сравнивать в процентном соотношении) людей интеллектуально развитых в последние два века стало больше, что обусловлено усложнением (с интеллектуальной точки зрения) человеческого труда.
5. Какая классическая рентабельность на рынке в России и Европах?
Вопрос слишком абстрактный. если мы об аутсорсинге, то для каждой компании это является коммерческой тайной, можно предполагать только.
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Тут многое будет зависеть от конкретного проекта. Не существует единого списка сопутствующих расходов. Опять же имеет значение какие виджы работ берет на себя компания, а какие поручает партнёрам, сторонним исполнителям, субподрядчикам и т.п. Отдельная статья — тестовые серверы, если они нужны, аудит, в банковских проектах и проектах с защитой данных и криптографией — тестирование на взлом, тут вариантов миллионы. Юридическое сопровождение.
Если компания продуктовая, то тут ещё сложнее.
4. Ну и элементарное, на что обратить ОСОБОЕ внимание, чтобы не упустить при расчете стоимости,?
Это очень абстрактный вопрос. Всё сильно зависит от проекта, области и т.д. Обычно дьявол сидит в сложной логике, на первый взгляд простых функций. Для того, чтобы не наступить на мину в этом вопросе лучше составить функциональную блок-схему описывающую логику, если она вызывает вопросы.
3. Как оценить время работы девелопера, в зависимости от сложности задачи?
Этим занимается тимлид(руководитель разработки), исходя из бизнес-требований описанных в ТЗ он назначает сотрудника уровень которого соответствует сложности задачи и определяет дедлайн на реализацию функции или процесса. Чем выше формализация в описании и точнее определены бизнес-требования, тем меньше ошибок будет на этом этапе.
2. Как рассчитывать постоянную составляющую (в советское время называлось обще-заводские), если в фирме несколько проектов в одно время?
Это зависит от методологии в рамках которой реализуются проекты. Не понимая как вы работаете не возможно что-то рассчитать. Если я правильно вас понял.
1. Как рассчитывать время на выполнение задачи (подзадачи)?
Если речь о SCRUM, то тимлид оценив пользовательские стори должен предположить сколько строчек кода уйдёт на реализацию каждой из них и таким образом оценить длительность спринта(короткой итерации в SCRUM), определив дедлайн в соответствии с количеством разработчиков которые трудятся в этом спринте. Если тимлид говорит, что на основании имеющихся данных не готов это сделать (с точностью до плюс минут 48 часов), значит сторис в спринте требуют большей формализации. Т.е нужно, чтобы бизнес-аналитик или при неимении такового менеджер проекта связался с заказчиком и попросил уточнений относительно работы функций. Иногда, если мы говорим о проектах со сложным пользовательским интерфейсом и интуитивно не понятными пользовательскими функциями перед оценкой нужно сделать прототип UX, в идеале функциональный прототип в Adobe XD. Если у функций продукта сложная логика, к некоторым стори (для достоверной оценки трудозатрат и времени реализации) имеет смысл нарисовать блок схемы, чтобы разработчик понимал логику. Психологии на этом этапе мало, много формализации и учета требований. Но это азы, которые должен знать любой менеджер проекта и бизнес-аналитик.
Я не писал об отказе от вербальной коммуникации, я рассматривал конкретные случаи в которых визуальная коммуникация более эффективна, писал о том, что в этих случаях компании парадоксально редко её используют. Писал, что в силу некоторого традиционализма люди принимающие решения не торопятся внедрять новые типы контента в тех отраслях, где они могут быть действительно востребованы, хотя технологических ограничений на их внедрение нет. И если мы говорим о коммерческих решениях — это фактически замедляет наступление ожидаемого будущего, является тормозом прогресса. Условно уровень технологий позволяет вам посетить Лондонский музей естествознания сидя на диване в Москве, или выбрать дом на Бали, но соответствующий контент пока не создан, и казалось бы заинтересованные отрасли очень медленно и вяло реагируют на появление технологий. Как-то вот так. При этом сложно не согласиться с тем, что массовое потребление требует наиболее простых, а порой примитивных решений, что действительно свидетельствует о деградации значительной части человечества. Но речь в статье, конечно, о другом.
Дело в том, что про это написано и переписано очень много материалов. В данном же случае есть некоторая некорректная вводная, которая не отражает реалий разработки и документального сопровождения разработки. По этой причине люди воздерживаются от комментов, задавать уточняющие вопросы в подобном случае долго, разбираться в том, что имел ввиду автор никто не хочет, это должно быть понятно из текста статьи, особенно если он посвящён созданию ТЗ).И да, я не припомню, чтобы на хабре писали посты о смене обоев на рабочем столе).
Привет, Владимир. Для сложных и больших проектов, предполагающих высокие риски созданы стандарты PMBOK, когда необходима высокая формализация требований имеет смысл применять нормы ГОСТ. Когда речь заходит об Agile-методологии при опросе заказчика создают user story (по крайней мере в SCRUM, хотя можно применять для описания бизнес-требований к функциям в любой методологии, например в KANBAN). Бизнес аналитики, PDM и тимлиды разработки обычно выбирают удобные им критерии и методы опроса заказчика, которые иногда зависят от выбранного стека и особенностей конкретного проекта (общих требований к результату). Если не понятна логика процесса или функции — рисуют блок схемы и прикрепляют к story, делят story на таски, детализируют до фрагментов функции или процессы. Чтобы обобщить и декомпозировать можно наклепать майндмэп. На каждом этапе это всё можно согласовывать. Возникает вопрос, зачем предложенный метод при использовании описанных типов ТЗ и методологий разработки? На каком этапе в приведенных типах ТЗ он применим? И ещё, приведённый гипотетически пример с Маарыйкой не соответствует лично моему практическому опыту. Обычно на каждом из этапов ТЗ усложняется и конкретизируется, в результате чего становится более подробным, но иногда менее интуитивно понятным (и вот тут на мой взгляд методы практической психологии могут помочь). В вашем же случае оно теряет значимые факты и сокращается, что в реальности маловероятно. Возможно я чего-то недопонял. Поясните, плиз.
Уточните, откуда вам известно как хотел композитор, если мы говорим не о наших современниках? Вся академическая классика — по сути, это сравнение интерпретаций и трактовок. Даже в отношении темпа и ритмики — вспомните трактовки Листа от Святослава Рихтера граничащие, порой, с импровизацией. Там интерпретации на пределе, но никто не приписывает Рихтеру авторство нового произведения и не пишет о том, что преступно исказил авторский замысел. Это если не касаться тонких нюансов. Динамический диапазон записи определяет не композитор, а возможности оборудования и звукорежиссер, который где считает правильным использует компрессор, а где не считает, не использует.
Я говорю о том, что физического труда стало меньше, интеллектуального больше.
«Какие именно массовые занятия интеллектуально усложнились, не подскажете?» подавляющее большинство. Компьютеризация призванная облегчить ряд процессов с другой стороны стимулировала человечество к освоению не свойственных ранее навыков, предрасположенность к освоению которых не была заложена генетически, что привело к появлению принципиально новых нейронных связей. Каким бы примитивным вам(в силу возраста, о котором вы упомянули) не казалось будущее поколение, оно неизбежно будет сложнее предыдущего, на уровне нейробиологии. Будущее, вероятнее всего, за исчезновением примитивного физического труда и автоматизацией массового производства. Это гарантированно изменит представление о человеческом труде, уже изменило, и все социальные аспекты с ним связанные, социальные лифты, распределение благ и т.д.
Вопрос слишком абстрактный. если мы об аутсорсинге, то для каждой компании это является коммерческой тайной, можно предполагать только.
6. Как рассчитывать сопутствующие расходы, косвенно связанные с проектом?
Тут многое будет зависеть от конкретного проекта. Не существует единого списка сопутствующих расходов. Опять же имеет значение какие виджы работ берет на себя компания, а какие поручает партнёрам, сторонним исполнителям, субподрядчикам и т.п. Отдельная статья — тестовые серверы, если они нужны, аудит, в банковских проектах и проектах с защитой данных и криптографией — тестирование на взлом, тут вариантов миллионы. Юридическое сопровождение.
Если компания продуктовая, то тут ещё сложнее.
Это очень абстрактный вопрос. Всё сильно зависит от проекта, области и т.д. Обычно дьявол сидит в сложной логике, на первый взгляд простых функций. Для того, чтобы не наступить на мину в этом вопросе лучше составить функциональную блок-схему описывающую логику, если она вызывает вопросы.
Этим занимается тимлид(руководитель разработки), исходя из бизнес-требований описанных в ТЗ он назначает сотрудника уровень которого соответствует сложности задачи и определяет дедлайн на реализацию функции или процесса. Чем выше формализация в описании и точнее определены бизнес-требования, тем меньше ошибок будет на этом этапе.
Это зависит от методологии в рамках которой реализуются проекты. Не понимая как вы работаете не возможно что-то рассчитать. Если я правильно вас понял.
Если речь о SCRUM, то тимлид оценив пользовательские стори должен предположить сколько строчек кода уйдёт на реализацию каждой из них и таким образом оценить длительность спринта(короткой итерации в SCRUM), определив дедлайн в соответствии с количеством разработчиков которые трудятся в этом спринте. Если тимлид говорит, что на основании имеющихся данных не готов это сделать (с точностью до плюс минут 48 часов), значит сторис в спринте требуют большей формализации. Т.е нужно, чтобы бизнес-аналитик или при неимении такового менеджер проекта связался с заказчиком и попросил уточнений относительно работы функций. Иногда, если мы говорим о проектах со сложным пользовательским интерфейсом и интуитивно не понятными пользовательскими функциями перед оценкой нужно сделать прототип UX, в идеале функциональный прототип в Adobe XD. Если у функций продукта сложная логика, к некоторым стори (для достоверной оценки трудозатрат и времени реализации) имеет смысл нарисовать блок схемы, чтобы разработчик понимал логику. Психологии на этом этапе мало, много формализации и учета требований. Но это азы, которые должен знать любой менеджер проекта и бизнес-аналитик.