Comments 10
Что самое страшное - сегодня к тезису "бизнес хочет" добавился "ИИ сказал, что это легко делается". Дуракам дали даже не гранату, а сразу атомную бомбу.
Ого! Даже такое бывает?
Если учесть, что нейросетки в целом "склонны" льстить, подчёркивать правоту и мотивировать, то вырисовывается так себе картинка... Это если руководитель опирается исключительно на "мнение" сетки или ставит его выше всего...
В целом, думаю, нет ничего зазорного спросить что-то у нейронки. Но надо держать в уме, что нейронка может льстить, ошибаться, что нужно посоветоваться с экспертами-людьми и что если есть расхождения, то неплохо бы запросить аргументацию и у тех, и у других :)
Это всегда было - "добавь фичу по-быстрому, там всё просто".
Что-то я не понял про экспериментальную версию. Кто параллельно ведёт разработку основной версии, если ещё не доказана эффективность эксперементальной? Ну и выделять два года на разработку экспериментальной версии в современном мире - это что-то странное
Спасибо за интерес! С удовольствием отвечу.
Я здесь не стал вдаваться в полную историю того продукта. Полный жизненный цикл там, конечно же, был довольно сложный. Более того, первые наработки по тому продукту появились за 8 лет до релиза, но затем на 5 с лишним лет разработка была заморожена по определённым причинам, которые я не могу здесь озвучивать (но кое-что скажу ниже, в следующем комментарии...) В общем, там и concept proof был, и иследование потребительского спроса, и многочисленные изменения в концепции, и отработка отдельных технологических этапов... Но это всё совсем другая история, которая увела бы нас в сторону от основной. Главное, что разработка на любых этапах велась в отрыве от финального вИдения продукта даже за 6 месяцев до релиза. Более того, финального вИдения вообще не существовало. Да, там идеально были отработаны отдельные технологические операции (которые по большей части осуществлялись софтом). Но вопросы интеграции, вписывания в существующую инфраструктуру, взаимодействия с клиентом и т.д. и т.п. не были проработаны совсем.
Конкретно я считаю, что разработка даже concept-proof версий не должна происходить совсем уж в вакууме. Всегда должно быть какое-то вИдение финальной архитектуры. Да, оно может быть неполным, может изменяться хоть каждый день, но оно должно быть. И разработка на любом шаге (возможно, кроме самого-самого начального) должна соответствовать общей архитектурной канве. Там могут быть отсутствующие "куски", могут быть упрощенные, но общая архитектура должна выдерживаться (даже если она периодически изменяется). И вопросы связывания отдельных "блоков" решения в общую картину должны прорабатываться так же, как и сами блоки/операции по отдельности. Именно в такой парадигме мне посчастливилось всегда работать вплоть до описанного случая.
Теперь немного философии не тему "сколько по времени может вестить экспериментальная разработка"...
Да сколько угодно! Есть множество причин, которые влияют на сроки.
1) Продукт может быть объективно технологически сложным. Например, космическая ракета или микропроцессор. Здесь на эспериментирования могут уйти многие годы. Одна очень известная микропроцессорная корпорация годами вела экспериментальные разработки, которые иногда полностью сворачивались
2) Продукт может опираться на технологию, которая пока ещё не дозрела. Например, пока нейронки не стали уверенно распознавать изображения, разработки, которые полагались на технологию распознавания, могли топтаться на месте в попытках доработать другие методы. Но как только нейронки взлетели - сразу много ещё чего взлетело. Что касается конкретно моего опыта, то могу сказать про системы хранения данных. Бывало, что обещана какая-то "магическая" железка, на базе которой начинается софтверная разработка. Но аппаратчики могут переносить сроки появления этой железки, менять концепцию железки или вообще никогда её не родить
3) Компания уже может иметь какой-то супер-успешный продукт, который приносит кучу денег. Поэтому новые разработки может вести вяло и небольшими силами
4) Основной продукт компании может быть прикрыт сильными патентами. И поэтому компания не заинтересована сильно продвигать экспериментальные решения до того, как начнёт истекать срок патента
5) Иногда компания может решить, что слишком сильно педалировать новые разработки невыгодно или даже опасно. Например, в прошлом или позапрошлом году одна фармкомпания была оштрафована на миллиарды долларов, потому что было показано, что у неё были доказательства эффективности нового продукта, но она не выводила его на рынок, потому что успешно продавала старый, который был защищён патентом. Соответственно, компания ждала, когда истечет патент, чтобы вывести новый продукт. Компанию обвинили во множестве смертей, которые могли бы не случиться, если бы более эффективное лекарство вывели на рынок сразу. Так что если бы компания затягивала с экспериментальным продуктом, то исков удалось бы избежать. Это, на мой вкус, звучит кощунственно, но фармкомпании могут думать иначе. Там каждый новый продукт требуетс вложений миллиардов баксов. Поэтому компании стремятся максимально отработать инвестиции в старый продукт, прежде чем выводить новый
В общем, мотивов или объективных сложностей может быть много... Это неисчепаемая тема...
👍
Накину на вентилятор «добра» еще манипулятивную тактику, с которыми сталкивался и сам, и которые, как оказалось, распространены.
В одной микро задаче требовалось просто посмотреть, какие метрики мы можем использовать на облаке для комплексного мониторинга. Задача на уровне: почитал доку - собрал - отдал. Отдал вместе с важным фактом, что для этого требуется DevOps. Но мы ведь хотим дешевле, быстрее и не за свой счет. Поэтому, т.к. я немного умею и не боюсь командной строки, об этом вспомнили. Началась подмена понятий:
- А мы можем сделать такое же, но сами? (?!)
- Есть метрики самого облака, они не отвечают на задачу, но их да — сделать могу и сам.
- А, т.е. мы можем сами сделать?
- Для именно этих метрик да, но не которые связаны с прометеусом, там уже другая область.
- Т.е. часть метрик можем сделать сами!
Как становится понятно, с этим новым знанием менеджер ушел, а через n-время в меня прилетела задача на установку мониторинга со всеми метриками. Ведь я же собрал и сказал, что могу их настроить :)
Возможный вывод: никогда не связывайся с менеджером, у которого поставлена задача экономить.
Был у меня когда то начальник, который прямо говорит всем "это мои подчиненные и я их е*у". Вот прямым текстом. Если кто то со стороны приходил, мол, "давай, ты нам должен" или "сладенький, любимый, ты самый лучший", откуда нибудь появлялся начальник и объяснял, куда идти и на каком агрегате вертеться. Кто то этого не понимает, возможно и я плохо понимал когда то. А потом понял. У каждого подчинённого есть свой план и круг обязанностей. Его кусок внутри отдела может влиять на весь отдел в целом. Был как то случай, когда один такой дурак пошел на поводу "горизонтальных взаимоотношений". В итоге ушел с головой, думал, свою работу успеет сделать. А нифига, разбился об собственный костыль. В итоге кое как успели в срок, а ему за такие финты ушами порезали премию и отдали другим людям в отделе. Тот, кому помог этот дурак, кстати тоже премию получил. И искреннее непонимание "а меня за что". А вывод прост: начальники и менеджеры иногда неспроста против, чтобы кто то лез за помощью к тем, кто в их ответственности. Вот будет работа выполнена, тогда занимайся чем хочешь. Только многие этого просто не понимают. И реально оказывается, что многие тупо не знают, как распоряжаться своим временем. Ну или знают, просто у них комплекс мученика.
Спасибо автору за эту замечательную и очень живую статью. Действительно, здорово, когда о таких важных, хоть и "невидимых" вещах говорят вслух, особенно с позиции практика, понимающего, как всё это влияет на код и результат в целом. Мне кажется, такие темы бесценны для сообщества, потому что заставляют задуматься о среде, в которой мы создаём технологии. Спасибо всем, кто делится своим опытом, это делает наше айти-сообщество только сильнее и человечнее!
«Бизнес хочет», менеджеры-князьки и другие болезни айтишной корпоративной культуры