Теперь немного философии не тему "сколько по времени может вестить экспериментальная разработка"...
Да сколько угодно! Есть множество причин, которые влияют на сроки.
1) Продукт может быть объективно технологически сложным. Например, космическая ракета или микропроцессор. Здесь на эспериментирования могут уйти многие годы. Одна очень известная микропроцессорная корпорация годами вела экспериментальные разработки, которые иногда полностью сворачивались 2) Продукт может опираться на технологию, которая пока ещё не дозрела. Например, пока нейронки не стали уверенно распознавать изображения, разработки, которые полагались на технологию распознавания, могли топтаться на месте в попытках доработать другие методы. Но как только нейронки взлетели - сразу много ещё чего взлетело. Что касается конкретно моего опыта, то могу сказать про системы хранения данных. Бывало, что обещана какая-то "магическая" железка, на базе которой начинается софтверная разработка. Но аппаратчики могут переносить сроки появления этой железки, менять концепцию железки или вообще никогда её не родить 3) Компания уже может иметь какой-то супер-успешный продукт, который приносит кучу денег. Поэтому новые разработки может вести вяло и небольшими силами 4) Основной продукт компании может быть прикрыт сильными патентами. И поэтому компания не заинтересована сильно продвигать экспериментальные решения до того, как начнёт истекать срок патента 5) Иногда компания может решить, что слишком сильно педалировать новые разработки невыгодно или даже опасно. Например, в прошлом или позапрошлом году одна фармкомпания была оштрафована на миллиарды долларов, потому что было показано, что у неё были доказательства эффективности нового продукта, но она не выводила его на рынок, потому что успешно продавала старый, который был защищён патентом. Соответственно, компания ждала, когда истечет патент, чтобы вывести новый продукт. Компанию обвинили во множестве смертей, которые могли бы не случиться, если бы более эффективное лекарство вывели на рынок сразу. Так что если бы компания затягивала с экспериментальным продуктом, то исков удалось бы избежать. Это, на мой вкус, звучит кощунственно, но фармкомпании могут думать иначе. Там каждый новый продукт требуетс вложений миллиардов баксов. Поэтому компании стремятся максимально отработать инвестиции в старый продукт, прежде чем выводить новый
В общем, мотивов или объективных сложностей может быть много... Это неисчепаемая тема...
Я здесь не стал вдаваться в полную историю того продукта. Полный жизненный цикл там, конечно же, был довольно сложный. Более того, первые наработки по тому продукту появились за 8 лет до релиза, но затем на 5 с лишним лет разработка была заморожена по определённым причинам, которые я не могу здесь озвучивать (но кое-что скажу ниже, в следующем комментарии...) В общем, там и concept proof был, и иследование потребительского спроса, и многочисленные изменения в концепции, и отработка отдельных технологических этапов... Но это всё совсем другая история, которая увела бы нас в сторону от основной. Главное, что разработка на любых этапах велась в отрыве от финального вИдения продукта даже за 6 месяцев до релиза. Более того, финального вИдения вообще не существовало. Да, там идеально были отработаны отдельные технологические операции (которые по большей части осуществлялись софтом). Но вопросы интеграции, вписывания в существующую инфраструктуру, взаимодействия с клиентом и т.д. и т.п. не были проработаны совсем.
Конкретно я считаю, что разработка даже concept-proof версий не должна происходить совсем уж в вакууме. Всегда должно быть какое-то вИдение финальной архитектуры. Да, оно может быть неполным, может изменяться хоть каждый день, но оно должно быть. И разработка на любом шаге (возможно, кроме самого-самого начального) должна соответствовать общей архитектурной канве. Там могут быть отсутствующие "куски", могут быть упрощенные, но общая архитектура должна выдерживаться (даже если она периодически изменяется). И вопросы связывания отдельных "блоков" решения в общую картину должны прорабатываться так же, как и сами блоки/операции по отдельности. Именно в такой парадигме мне посчастливилось всегда работать вплоть до описанного случая.
Ого! Даже такое бывает? Если учесть, что нейросетки в целом "склонны" льстить, подчёркивать правоту и мотивировать, то вырисовывается так себе картинка... Это если руководитель опирается исключительно на "мнение" сетки или ставит его выше всего... В целом, думаю, нет ничего зазорного спросить что-то у нейронки. Но надо держать в уме, что нейронка может льстить, ошибаться, что нужно посоветоваться с экспертами-людьми и что если есть расхождения, то неплохо бы запросить аргументацию и у тех, и у других :)
Да, люди, выдавленные ею из компании, нашли себе хорошие места для дальнейшей работы. Пострадала компания в целом и конкретные команды, которых лишили классных руководителей. Некоторые команды особенно жаль, потому что вместо опытных эффективных директоров они получили дурачков, вообще не понимающих реалии разработки софта (но при этом действующих в интересах той тёти).
Тётку не уволили, тётка с тех пор захватила ещё больше власти. Компания пока тоже не развалилась. Всё-таки это транснациональная корпорация, и одна тётка её не развалит, даже если это будет CEO. Но тем не менее, постепенная деградация идёт. Адекватных людей всё меньше, инноваций нет, акции стабильно снижаются уже несколько лет
Про задачки, приближенные к практике, я согласен. Сам постоянно даю такие. Собственно, задача, которую кандидат отказался брать на дом, была такой. Я специально придумал её таким образом, чтобы она была творческой и приближенной к реальным потребностям конторы.
Но на мой вкус, модельные задачи важны, однако не заменяют реального "боевого" опыта. К тому же более-менее крупные задачи легко давать младшим и средним специалистам, а старшие специалисты часто от них отказываются. Понятно, что если вакансия очень лакомая, и на неё прямо ломятся лучшие специалисты, то можно любые условия выставлять. Но далеко не все вакансии такие. Так что приходится подстраиваться под реалии и учитывать, что от творческой задачи кандидат может отказаться (но при этом это все равно может быть подходящий кандидат)
Я всегда уделяю большое внимание опыту кандидата. Во-первых, так я узнаю о жизни других компаний и, возможно, даже сам чему-то учусь. Во-вторых, люди, которые идеально решают модельные задачи (которые я предлагаю им на собеседовании), но не умеют решать практические задачи, для меня не выглядят подходящими кандидатами.
Хочу даже написать статью (видимо, уже не для Хабра) про выявление практического опыта кандидата. Дело в том, что про него часто врут. Иногда даже старшие разработчики
А можете привести 1-2 примера ваших удачных запросов к GPT? Интересно посмотреть, в чем именно модель оказалась полезной, а также как именно люди формулируют свои запросы к ней
Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.
В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.
По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин: 1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях 2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату 3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).
Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.
Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.
Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал
Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...
Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.
Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.
Да, к сожалению, наш контроль над нашими же смартфонами далек от полного… И пользовательские соглашения для приложений все больше напоминают историю: «соглашайтесь на всё или никакого сервиса не получите».
Внешних карт памяти у меня нет. Все, что я сделал после покупки нового телефона, — это вошел с него в аккаунт Google и воспользовался функцией восстановления приложений. Контакты и настройки приложений — это единственно, что у меня бэкапится в облако. Все остальные бэкапы (в том числе и на уровне приложений) запрещены.
Думаю, работа «в склад» действительно может случаться на некоторых производствах при определенной конъюнктуре. Там, где остановка производственных мощностей очень дорого обходится. Например, остановка (и обратный запуск) нефтяной скважины — дело очень затратное.
Поэтому если в краткосрочном периоде цена уходит ниже себестоимости, возможно, есть смысл поработать в хранилище.
Но в большинстве случаев такого, конечно, не бывает.
С DRAM как раз ситуация обратная. В этом году цены практически на все компы выросли из-за недостатка памяти на рынке. Производители памяти знали о ситуации, но предпочли не инвестировать в дополнительное производство. Вместо этого взвинтили цены. Отсюда и подорожание всего остального, в чем есть память. Но это длинная история. Там много интересных моментов. Вот для затравочки:
http://www.dramexchange.com/WeeklyResearch/Post/2/4563.html
http://www.dramexchange.com/WeeklyResearch/Post/2/4618.html
Полностью согласен
Теперь немного философии не тему "сколько по времени может вестить экспериментальная разработка"...
Да сколько угодно! Есть множество причин, которые влияют на сроки.
1) Продукт может быть объективно технологически сложным. Например, космическая ракета или микропроцессор. Здесь на эспериментирования могут уйти многие годы. Одна очень известная микропроцессорная корпорация годами вела экспериментальные разработки, которые иногда полностью сворачивались
2) Продукт может опираться на технологию, которая пока ещё не дозрела. Например, пока нейронки не стали уверенно распознавать изображения, разработки, которые полагались на технологию распознавания, могли топтаться на месте в попытках доработать другие методы. Но как только нейронки взлетели - сразу много ещё чего взлетело. Что касается конкретно моего опыта, то могу сказать про системы хранения данных. Бывало, что обещана какая-то "магическая" железка, на базе которой начинается софтверная разработка. Но аппаратчики могут переносить сроки появления этой железки, менять концепцию железки или вообще никогда её не родить
3) Компания уже может иметь какой-то супер-успешный продукт, который приносит кучу денег. Поэтому новые разработки может вести вяло и небольшими силами
4) Основной продукт компании может быть прикрыт сильными патентами. И поэтому компания не заинтересована сильно продвигать экспериментальные решения до того, как начнёт истекать срок патента
5) Иногда компания может решить, что слишком сильно педалировать новые разработки невыгодно или даже опасно. Например, в прошлом или позапрошлом году одна фармкомпания была оштрафована на миллиарды долларов, потому что было показано, что у неё были доказательства эффективности нового продукта, но она не выводила его на рынок, потому что успешно продавала старый, который был защищён патентом. Соответственно, компания ждала, когда истечет патент, чтобы вывести новый продукт. Компанию обвинили во множестве смертей, которые могли бы не случиться, если бы более эффективное лекарство вывели на рынок сразу. Так что если бы компания затягивала с экспериментальным продуктом, то исков удалось бы избежать. Это, на мой вкус, звучит кощунственно, но фармкомпании могут думать иначе. Там каждый новый продукт требуетс вложений миллиардов баксов. Поэтому компании стремятся максимально отработать инвестиции в старый продукт, прежде чем выводить новый
В общем, мотивов или объективных сложностей может быть много... Это неисчепаемая тема...
Спасибо за интерес! С удовольствием отвечу.
Я здесь не стал вдаваться в полную историю того продукта. Полный жизненный цикл там, конечно же, был довольно сложный. Более того, первые наработки по тому продукту появились за 8 лет до релиза, но затем на 5 с лишним лет разработка была заморожена по определённым причинам, которые я не могу здесь озвучивать (но кое-что скажу ниже, в следующем комментарии...) В общем, там и concept proof был, и иследование потребительского спроса, и многочисленные изменения в концепции, и отработка отдельных технологических этапов... Но это всё совсем другая история, которая увела бы нас в сторону от основной. Главное, что разработка на любых этапах велась в отрыве от финального вИдения продукта даже за 6 месяцев до релиза. Более того, финального вИдения вообще не существовало. Да, там идеально были отработаны отдельные технологические операции (которые по большей части осуществлялись софтом). Но вопросы интеграции, вписывания в существующую инфраструктуру, взаимодействия с клиентом и т.д. и т.п. не были проработаны совсем.
Конкретно я считаю, что разработка даже concept-proof версий не должна происходить совсем уж в вакууме. Всегда должно быть какое-то вИдение финальной архитектуры. Да, оно может быть неполным, может изменяться хоть каждый день, но оно должно быть. И разработка на любом шаге (возможно, кроме самого-самого начального) должна соответствовать общей архитектурной канве. Там могут быть отсутствующие "куски", могут быть упрощенные, но общая архитектура должна выдерживаться (даже если она периодически изменяется). И вопросы связывания отдельных "блоков" решения в общую картину должны прорабатываться так же, как и сами блоки/операции по отдельности. Именно в такой парадигме мне посчастливилось всегда работать вплоть до описанного случая.
Ого! Даже такое бывает?
Если учесть, что нейросетки в целом "склонны" льстить, подчёркивать правоту и мотивировать, то вырисовывается так себе картинка... Это если руководитель опирается исключительно на "мнение" сетки или ставит его выше всего...
В целом, думаю, нет ничего зазорного спросить что-то у нейронки. Но надо держать в уме, что нейронка может льстить, ошибаться, что нужно посоветоваться с экспертами-людьми и что если есть расхождения, то неплохо бы запросить аргументацию и у тех, и у других :)
Да, люди, выдавленные ею из компании, нашли себе хорошие места для дальнейшей работы. Пострадала компания в целом и конкретные команды, которых лишили классных руководителей. Некоторые команды особенно жаль, потому что вместо опытных эффективных директоров они получили дурачков, вообще не понимающих реалии разработки софта (но при этом действующих в интересах той тёти).
Тётку не уволили, тётка с тех пор захватила ещё больше власти. Компания пока тоже не развалилась. Всё-таки это транснациональная корпорация, и одна тётка её не развалит, даже если это будет CEO. Но тем не менее, постепенная деградация идёт. Адекватных людей всё меньше, инноваций нет, акции стабильно снижаются уже несколько лет
Спасибо за подробный рассказ о вашем подходе! Очень интересно!
Про задачки, приближенные к практике, я согласен. Сам постоянно даю такие. Собственно, задача, которую кандидат отказался брать на дом, была такой. Я специально придумал её таким образом, чтобы она была творческой и приближенной к реальным потребностям конторы.
Но на мой вкус, модельные задачи важны, однако не заменяют реального "боевого" опыта. К тому же более-менее крупные задачи легко давать младшим и средним специалистам, а старшие специалисты часто от них отказываются. Понятно, что если вакансия очень лакомая, и на неё прямо ломятся лучшие специалисты, то можно любые условия выставлять. Но далеко не все вакансии такие. Так что приходится подстраиваться под реалии и учитывать, что от творческой задачи кандидат может отказаться (но при этом это все равно может быть подходящий кандидат)
Спасибо за интерес!
Я всегда уделяю большое внимание опыту кандидата. Во-первых, так я узнаю о жизни других компаний и, возможно, даже сам чему-то учусь. Во-вторых, люди, которые идеально решают модельные задачи (которые я предлагаю им на собеседовании), но не умеют решать практические задачи, для меня не выглядят подходящими кандидатами.
Хочу даже написать статью (видимо, уже не для Хабра) про выявление практического опыта кандидата. Дело в том, что про него часто врут. Иногда даже старшие разработчики
Ого! Фудаментально :) Спасибо за примеры!
А можете привести 1-2 примера ваших удачных запросов к GPT? Интересно посмотреть, в чем именно модель оказалась полезной, а также как именно люди формулируют свои запросы к ней
Спасибо за отклик!
Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.
В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.
По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин:
1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях
2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату
3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).
Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.
Спасибо за интерес!
Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.
Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал
Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...
Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.
Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.
Поэтому если в краткосрочном периоде цена уходит ниже себестоимости, возможно, есть смысл поработать в хранилище.
Но в большинстве случаев такого, конечно, не бывает.
http://www.dramexchange.com/WeeklyResearch/Post/2/4563.html
http://www.dramexchange.com/WeeklyResearch/Post/2/4618.html