Допустим, в команду которая знает только X, на поддержку попал сторонний продукт на Y от более несуществующей команды. Написан ужасно (оригинальные разработчики уже ничего в свою защиту не скажут).
Команда получает добро на переписывание этого стороннего продукта с нуля на X. Так как все продукты в компании написаны на X, а нанимать программиста с знанием Y не хотят.
Разумно ли это с точки зрения проектного управления?
Как часто и почему такое встречается? Встречалось ли на вашем опыте такое?
Здравствуйте, Артём, Вы писали:
Аё>Команда получает добро на переписывание этого стороннего продукта с нуля на X. Так как все продукты в компании написаны на X, а нанимать программиста с знанием Y не хотят.
В именно такой постановке с переписыванием не сталкивался. Было так:
Был сервис, начало которого стартовало в 1991-92 году. Написан на Си и С++. Работал под Win32, Linux, Solaris, HPUX. В какой-то момент руководство приняло решение приткнуть этот сервис к остальным на сервер приложений. Дали команду переписать на яве. Два с++ программиста взяли методичку и за 24 человека/месяца переписали.
Аё>Разумно ли это с точки зрения проектного управления?
Код на Яве поддерживать проще, чем на си. Многопоточность с учетом кроссплатформенности + несколько версий субд.
_____________________
С уважением,
Stanislav V. Zudin
Аё>Разумно ли это с точки зрения проектного управления? Аё>Как часто и почему такое встречается? Встречалось ли на вашем опыте такое?
Встречалось что-то такое. Но переписывание это процесс не быстрый, может на годы растянутся (в зависимости от размера и сложности проекта), а в это время нужно поддерживать сторонний продукт Y.
Т.е. программист с знанием Y всё равно нужен. В т.ч. для консультаций переписывающей команды.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Код на Яве поддерживать проще, чем на си. Многопоточность с учетом кроссплатформенности + несколько версий субд.
Аё>Допустим, в команду которая знает только X, на поддержку попал сторонний продукт на Y от более несуществующей команды. Написан ужасно (оригинальные разработчики уже ничего в свою защиту не скажут).
Аё>Команда получает добро на переписывание этого стороннего продукта с нуля на X. Так как все продукты в компании написаны на X, а нанимать программиста с знанием Y не хотят.
Аё>Разумно ли это с точки зрения проектного управления?
Стоит ли овчинка выделки или нет — зависит от очень многих факторов.
Прежде всего — в чем заключается "поддержка"? Фиксить баги, конфигурировать, реализовывать мелкие хотелки пользователей или же серьезно развивать дальше?
Насколько приоритетна поддержка? Если возник какой-то кейс, связанный с поддержкой — его надо закрывать прям срочно или можно неспешно?
Продукт Y — критичный? Если в нем что-то сбойнет — это совсем пипец или не очень страшно?
И альтернатива переписыванию — это обязательно "нанимать программиста с знанием Y"? Или, может, достаточно, чтобы кто-то из программистов со знанием X чутка подучил Y (без претензий на то, чтобы дорасти до уровня профи в Y, но на достаточном уровне, чтобы подкручивать всякую мелочевку)? Или есть вариант не нанимать насовсем программиста Y, а обращаться к такому за консультациями или заказывать у него какие-то разовые работы?
Аё>Разумно ли это с точки зрения проектного управления? Аё>Как часто и почему такое встречается? Встречалось ли на вашем опыте такое?
Если работники на рынке труда есть и технология не сильно древняя, и есть инструменты продуктивной разработки, то неразумно.
Один раз было. Кончилось плохо.
Начали случайно переписывать не с того конца, функции, которые наименее актуальны для бизнеса.
В коде сделали миллион примитивных багов тк переписывали глядя в старый код, а не в документацию, которой не было.
Без глубокого понимания бизнес-логики результат напоминает машинный перевод текста — вроде дословно правильно, но в целом — лажа.
Здравствуйте, Артём, Вы писали:
Аё>Допустим, в команду которая знает только X, на поддержку попал сторонний продукт на Y от более несуществующей команды. Написан ужасно (оригинальные разработчики уже ничего в свою защиту не скажут). Аё>Команда получает добро на переписывание этого стороннего продукта с нуля на X. Так как все продукты в компании написаны на X, а нанимать программиста с знанием Y не хотят. Аё>Разумно ли это с точки зрения проектного управления? Аё>Как часто и почему такое встречается? Встречалось ли на вашем опыте такое?
Я такое делал. Решалось просто — берешь запрашиваешь у HR отдела затраты и временные сроки найма нужного количества программистов на Y + тех лида для них для проекта + QA готового делать автоматизацию тестирования для Y технологии. Плюс оцениваешь время на онбоардинг и время ознакомления с проектом этих программистов.
Потом считаешь сколько будет тебе стоить портирование — по времени и срокам и найму дополнительному программистов на X. В моем случае подразумевалось что тел лид + менеджеры + QA будет текущие — так что мы тут можем очень точно назвать суммы.
У тебя есть два срока и две суммы — ты их просто сравниваешь и делаешь выбор.
В моем случае выбор был уже очевиден на этом этапе и оценку там самих технологий, как это повлияет на мотивацию основнйо команды и прочее можно было не учитывать. Ха.
Аё>Разумно ли это с точки зрения проектного управления?
Как правило, нет, но исключения бывают.
Аё>Как часто и почему такое встречается?
Зависит от масштабов "проекта Y", чем больше этот проект, тем меньше шансов на переписывание (и это правильно).
Аё>Встречалось ли на вашем опыте такое?
Встречалось. В тех случаях, что я упомню, процесс "переписывания" был начат, но так никогда и не был закончен. Потому что либо "продукт Y" сам по себе протух (его перестали покупать, за него перестали платить) и его просто дропнули, либо переписывание стопорнулось где-то посередине, и оба продукта сосуществовали.
Здравствуйте, Артём, Вы писали:
SVZ>>Код на Яве поддерживать проще, чем на си. Многопоточность с учетом кроссплатформенности + несколько версий субд. Аё>X — Angular 2x Аё>Y — React
А это прямо нереально разные технологии? Это же, по сути, два похожих фреймворка, для
которых используется один и тот же язык -- либо ts, либо js. Лично мне кажется, что
тут ситуация сущ. проще, чем, например, с цпп на яву переписывать. Или еще хуже -- наоборот.
Здравствуйте, Sharov, Вы писали:
S>А это прямо нереально разные технологии? Это же, по сути, два похожих фреймворка, для S>которых используется один и тот же язык -- либо ts, либо js. Лично мне кажется, что
Это разные конкурирующие фреймворки. Холивар как между жава и сипипи. Технически возможно залинковать оба фреймворка в один апп- чтобы не переписывать компонент. Но в случае, что я наблюдаю- именно собрались переписать фронт с нуля с реакта на ангулар.
На моём проекте раньше был коллега, который тянул в сторону "переписать фронт с нуля с ангулара на реакт" и из-за него пожгли много много человеко-часов, страдая фигнёй. Потом он ушёл, а мины, им оставленные, напоминают в проблемами в проде да сих пор.
Здравствуйте, Артём, Вы писали:
Аё>Команда получает добро на переписывание этого стороннего продукта с нуля на X. Так как все продукты в компании написаны на X, а нанимать программиста с знанием Y не хотят. Аё>Разумно ли это с точки зрения проектного управления?
да. Писать надо на том, что знаешь.
Аё>Как часто и почему такое встречается?
не очень часто. Причины: смена архитектуры/OS или конец поддержки платформы для Y. (Редко — производительность)
Аё> Встречалось ли на вашем опыте такое?
Дважды наблюдал со стороны, 1 раз писал сам.
Главная опасность — не знание бизнес логики. Нужен консультант, который понимает, что должно получится в итоге. Иначе будут сделаны все те же ошибки, что есть в старом проекте, + добавлены свои.
Лучше было бы сразу написать, о чем речь. Скорее всего, многие подумали о разных языках.
А в данном случае вообще нет никакой проблемы для опытного разработчика сменить Ангуляр на Реакт. Единственное, могут начать упрямиться по идеологическим причинам. Ну тут уж вопросы к профессионализму оных. Там суть одна и та же, концепции все похожи. Ну ок, максимум неделя — и уже как на родном будут писать.
Здравствуйте, Артём, Вы писали:
Аё>Разумно ли это с точки зрения проектного управления?
Управление проектом здесь не при чем от солова совсем. Разумно ли это с точки зрения бизнеса? Так такие вопросы сам же бизнес и решает. Если бизнеса дали свое согласие на подобный переход — значит ОК.
Аё>Как часто и почему такое встречается? Встречалось ли на вашем опыте такое?
Конечно встречается. И часто. Наиболее частые переходы из мое практики были: Delphi → Java (абсолютный рекордсмен по востребованности)
PL/SQL (T-SQL) → Java
C → C++11/C++14
Delphi -> C#
прикладная языковая муть ETL (SQL) → Python
Чем обусловлены такие переходы? В основном — слишком большей стоимостью сопровождения. Если стоимость сопровождения больше чем (будущая стоимость сопровождения + будущая стоимость разработки) — то конечно, целесообразно переходить. Если в конторе есть хелп деск по всяким ITIL, то такая разработка стартует с пол-пинка с показом красивых слайдов о том сколько тикетов не будет приходит на тиры хелп-деска.
Здравствуйте, Артём, Вы писали:
Аё>Команда получает добро на переписывание этого стороннего продукта с нуля на X. Так как все продукты в компании написаны на X, а нанимать программиста с знанием Y не хотят.
Аё>Разумно ли это с точки зрения проектного управления?
Если компания большая, оценка стоимости переписывания умноженная на Pi бизнес не смущает, то почему бы нет?
Вопрос в другом: разумно ли это с точки зрения команды?
1) Проект меньше нескольких человеко-лет?
2) Существует ли исчерпывающая документация по требованиям?
3) Команда имеет экспертизу в проекте? Условно, есть глубокое понимание, как оно все работает?
Если все три ответа "да", успех вероятен.
Если все три "нет" — ну... ищите новую работу, что ли. Потому что эта скоро закончится.
Если какие-то ответы "да", а какие-то "нет" — то успех конечно возможен, но маловероятен.
В твоем случае ответ на 3-й вопрос однозначно "нет", ведь если команда даже не знает Y, как она может быть экспертой в проекте, который написан на Y/
Аё>Как часто и почему такое встречается? Встречалось ли на вашем опыте такое?
Видел несколько неусешных попыток, застрявших посередине.
Видел пару "удачных" попыток, когда переписанное выходило в прод с превышением сроков и бюджетов в 2-4 раза.
Здравствуйте, Gradiens, Вы писали:
G>В твоем случае ответ на 3-й вопрос однозначно "нет", ведь если команда даже не знает Y, как она может быть экспертой в проекте, который написан на Y/
Почему нет? Знают предметную область, не знают технологию-- шансы есть, и неплохие.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Gradiens, Вы писали:
G>>В твоем случае ответ на 3-й вопрос однозначно "нет", ведь если команда даже не знает Y, как она может быть экспертой в проекте, который написан на Y/
S>Почему нет? Знают предметную область, не знают технологию-- шансы есть, и неплохие.
Шансы конечно есть.
Но не стоит путать знание домена и знание самого проекта. Я не в курсе конкретно этого проекта, однако видел много проектов, по которым документации или не было, или она неполная и безнадежно устаревшая. Команда уволилась, как оно на самом деле работает — никто не знает.
И при переписывании надо не просто сделать красиво. Надо повторить неявняй функционал, который кому-то нужен. При этом избавиться от того, чем никто не пользуется.
