Молодец, так держать!
Сам сейчас готовлю к релизу свою первую игру, многое из сказанного в статье тоже пришлось пройти.
Главный совет, который могу дать, начинай делать следующую игру независимо от финансовых показателей этой. Сам себе повторяю это как мантру тем чаще, чем ближе релиз :)
Стоит добавить, что строить модель предметной области достаточно сложно и долго.
Человек, который в начале статьи задавал свой вопрос, не уточнил, что у него за задача. Поэтому полученный им ответ вполне может быть релевантным. Если CRUD приложение решит его задачу, то не за чем искать сложностей. Это будет анемичная модель в процедурном стиле, а такая архитектура будет архитектурой с анемичной моделью. Да и хрен бы с ней, пока она может эффективно решать задачу.
Очень актуальная статья, сам ищу информацию на тему управления продуктом в крупном B2B. И на данный момент у меня сформировалось не очень радужное мнение о том, что весь хайп вокруг продакт менеджмента — это хайп только вокруг B2C.
В энтерпрайзе же слово «продукт» имеет второстепенную роль. Очень длинный и неочевидный цикл продаж, большое количество непродуктовых факторов, очень сильная кастомизированность. Всё это превращает продукт в проект. В заказную разработку, когда слово «продукт» употребляется уже только в смысле «мы вам напишем не с нуля, а у нас есть уже что-то готовое».
Могут ли существовать продукты для B2B? Да, в виде платформ. И по модели дилерской сети. Есть вендор и есть его партнеры-интеграторы. Но ничего общего с нынешним хайповым понятием «продакт менеджмент» я в таких платформах не вижу.
Я было хотел написать комментарий, но потом стало лениво, да и смысла нет.
Но этот текст я уже написал, а удалять тоже лень, так что нажму, пожалуй, кнопку Отправить.
Да вот судя даже по программе их курса ( pm.mail.ru/curriculum/program/main ), продакт включает в себя бОльшую часть проджекта.
Организация разработки, работа с командой, выбор технологий, организация тестирования — это всё тоже входит.
Я надеюсь, что в вашей академии смогут показать и рассказать о продукт менеджерах намного лучше, чем это сделано в этой статье.
Мне, как интересующемуся предметом, всё никак не станет понятно, как соотносятся продакт и проджект менеджеры.
Очень смешные результаты :)
Все аналитики твёрдо сходятся в том, что они понимают, когда и как документировать функционал. Также все они своевременно актуализируют документацию, аж на 106% (или это чудеса Вашей нормировки?).
И как результат работы — документация полна и актуальна с уверенностью 0,13.
Молодцы аналитики!
Такое ощущение, что пришел новый человек (ИТ-директор или корпоративный архитектор) и решил наводить порядок. Интересно будет почитать следующие статьи, понаблюдать за воплощением инициативы.
Скажите, пожалуйста, эту активность по каталогизации систем вы рассматриваете как первый шаг построения энтерпрайз архитектуры?
К слову про Москву-Октябрьскую. Был случай во время ЧМ, в метро увидел мексиканца, которого наши бравые дежурные у турникетов отправляли на станцию метро Октябрьская.
Помог туристу разобраться, потом ехали в метро, вместе смеялись. На билете в Санкт-Петербург написана станция отправления Москва-Октябрьская, являющаяся Ленинградским вокзалом, находящимся на станции метро Комсомольская.
Поддержу предыдущие комментарии о том, что принципы программирования — это инструменты, а не самоцель, а также что в классе посылки не должно быть логики.
Зачем посылке вообще атрибут isUrgent? Это верный путь к конструкциям типа if(parcel.isUrgent()) {
// fast delivery
} else {
// usual delivery
}
Посылка не должна знать, как надо ее доставлять. Эту задачу на себя берёт «доставщик». Обычная посылка и срочная посылка — это одна и та же посылка, которую доставляют разные доставщики. Паттерн стратегия.
Спасибо за статью как за попытку найти объяснение выгоды облаков. Пока что, к сожалению, не убедили.
Заголовок громкий, но статья его не раскрывает (да, это же пресейл). Крупные заказчики все время хотят занижать капитальные затраты, например, нанимая дорогой консалтинг вместо содержания своего штата. И ничего общего с облаками здесь нет.
И второй момент, который вы безусловно знаете, но почему-то (намеренно?) не упомянаете — это безопасники. Вот кто на самом деле хочет иметь стойки с серверами «дома», а вовсе не CIO.
И зачастую с безопасниками ни CFO, ни даже CEO связываться не хотят. Безопасность облака — это уже тема отдельной статьи. Если соберетесь написать об этом, с удовольствием почитаю!
Даю обратную связь: очень интересный заголовок статьи и очень поверхностное содержание. В статье нет ничего про «традиционную компанию», а только про проблему создания нового продукта.
Статья неплохая, освежила память, хоть и смахивает на реферат. Неплохой реферат )
Есть один тонкий момент, который мог бы сделать из просто неплохой статьи по-настоящему ценную. В агрегации приводится метод addEmployee класса Department. И в этом методе производятся сразу два действия: 1) добавление работника в массив работников отдела и 2) указание отдела в объекте работника.
Если следовать данной логике, то как минимум в методе removeEmployee надо не забыть почистить отдел у сотрудника, а не просто удалить сотрудника из массива.
А как максимум — нужно ли нагружать класс Department дополнительной ответственностью? Не просто добавлять сотрудника в свой массив, но и сообщать сотруднику о себе?
А может наоборот, в методе setDepartment класса Employee надо вызывать department.addEmployee(this)?
А может вообще сделать некий промежуточный класс «отдел кадров», который будет выполнять оба действия: сообщать сотруднику его отдел и сообщать отделу о новом сотруднике?
На мой взгляд, вывод в статье должен быть в том, что переход от UML к коду — это может быть и не так сложно, но вот прийти к самому UML — это дело другого уровня. Это задача проектирования предметной области. На эту тему можно начать с чтения Эрика Эванса.
Соглашусь частично. Действительно, должен быть класс Position, у которого есть свойства name и department.
А у сотрудника Employee должны быть свойства currentPosition и pastPositions[]. Сливать текущую и прошлые позиции в один массив я бы не стал, это все же разные сущности. Хранить текущую позицию в positions[0] — это совсем не clear.
Сам сейчас готовлю к релизу свою первую игру, многое из сказанного в статье тоже пришлось пройти.
Главный совет, который могу дать, начинай делать следующую игру независимо от финансовых показателей этой. Сам себе повторяю это как мантру тем чаще, чем ближе релиз :)
Человек, который в начале статьи задавал свой вопрос, не уточнил, что у него за задача. Поэтому полученный им ответ вполне может быть релевантным. Если CRUD приложение решит его задачу, то не за чем искать сложностей. Это будет анемичная модель в процедурном стиле, а такая архитектура будет архитектурой с анемичной моделью. Да и хрен бы с ней, пока она может эффективно решать задачу.
В энтерпрайзе же слово «продукт» имеет второстепенную роль. Очень длинный и неочевидный цикл продаж, большое количество непродуктовых факторов, очень сильная кастомизированность. Всё это превращает продукт в проект. В заказную разработку, когда слово «продукт» употребляется уже только в смысле «мы вам напишем не с нуля, а у нас есть уже что-то готовое».
Могут ли существовать продукты для B2B? Да, в виде платформ. И по модели дилерской сети. Есть вендор и есть его партнеры-интеграторы. Но ничего общего с нынешним хайповым понятием «продакт менеджмент» я в таких платформах не вижу.
Объявить тему выступления «десять ошибок», а рассказать о трёх.
Интересно было бы почитать, что вы успели сделать за полтора года, как пришли к нынешней точке.
Так может быть пользователи обновлялись не потому что вы внедрили супер фоновый режим IAUs, а просто потому что предложили обновиться?
А контрольной группе сообщений с предложением обновиться не было?
Я было хотел написать комментарий, но потом стало лениво, да и смысла нет.
Но этот текст я уже написал, а удалять тоже лень, так что нажму, пожалуй, кнопку Отправить.
Организация разработки, работа с командой, выбор технологий, организация тестирования — это всё тоже входит.
Мне, как интересующемуся предметом, всё никак не станет понятно, как соотносятся продакт и проджект менеджеры.
Все аналитики твёрдо сходятся в том, что они понимают, когда и как документировать функционал. Также все они своевременно актуализируют документацию, аж на 106% (или это чудеса Вашей нормировки?).
И как результат работы — документация полна и актуальна с уверенностью 0,13.
Молодцы аналитики!
Скажите, пожалуйста, эту активность по каталогизации систем вы рассматриваете как первый шаг построения энтерпрайз архитектуры?
Поясните, пожалуйста, для кого бесплатное?
К слову про Москву-Октябрьскую. Был случай во время ЧМ, в метро увидел мексиканца, которого наши бравые дежурные у турникетов отправляли на станцию метро Октябрьская.
Помог туристу разобраться, потом ехали в метро, вместе смеялись. На билете в Санкт-Петербург написана станция отправления Москва-Октябрьская, являющаяся Ленинградским вокзалом, находящимся на станции метро Комсомольская.
Зачем посылке вообще атрибут isUrgent? Это верный путь к конструкциям типа
if(parcel.isUrgent()) {
// fast delivery
} else {
// usual delivery
}
Посылка не должна знать, как надо ее доставлять. Эту задачу на себя берёт «доставщик». Обычная посылка и срочная посылка — это одна и та же посылка, которую доставляют разные доставщики. Паттерн стратегия.
Спасибо за статью как за попытку найти объяснение выгоды облаков. Пока что, к сожалению, не убедили.
Заголовок громкий, но статья его не раскрывает (да, это же пресейл). Крупные заказчики все время хотят занижать капитальные затраты, например, нанимая дорогой консалтинг вместо содержания своего штата. И ничего общего с облаками здесь нет.
И второй момент, который вы безусловно знаете, но почему-то (намеренно?) не упомянаете — это безопасники. Вот кто на самом деле хочет иметь стойки с серверами «дома», а вовсе не CIO.
И зачастую с безопасниками ни CFO, ни даже CEO связываться не хотят. Безопасность облака — это уже тема отдельной статьи. Если соберетесь написать об этом, с удовольствием почитаю!
Во-первых, беСсерверная.
Во-вторых, придумали уже термин PaaS. Ваш FaaS = PaaS.
В-третьих, не каждую статью стоит переводить.
Есть один тонкий момент, который мог бы сделать из просто неплохой статьи по-настоящему ценную. В агрегации приводится метод addEmployee класса Department. И в этом методе производятся сразу два действия: 1) добавление работника в массив работников отдела и 2) указание отдела в объекте работника.
Если следовать данной логике, то как минимум в методе removeEmployee надо не забыть почистить отдел у сотрудника, а не просто удалить сотрудника из массива.
А как максимум — нужно ли нагружать класс Department дополнительной ответственностью? Не просто добавлять сотрудника в свой массив, но и сообщать сотруднику о себе?
А может наоборот, в методе setDepartment класса Employee надо вызывать department.addEmployee(this)?
А может вообще сделать некий промежуточный класс «отдел кадров», который будет выполнять оба действия: сообщать сотруднику его отдел и сообщать отделу о новом сотруднике?
На мой взгляд, вывод в статье должен быть в том, что переход от UML к коду — это может быть и не так сложно, но вот прийти к самому UML — это дело другого уровня. Это задача проектирования предметной области. На эту тему можно начать с чтения Эрика Эванса.
А у сотрудника Employee должны быть свойства currentPosition и pastPositions[]. Сливать текущую и прошлые позиции в один массив я бы не стал, это все же разные сущности. Хранить текущую позицию в positions[0] — это совсем не clear.