Комментарии 32
И в других отраслях также! Спасибо!
" зафичатоглить " О Всемогучий, что за суржик? Просто кровь из ушей. Как это разслышать взад?
Для меня вообще так и осталось тайной что это слово означает.
Вот так теряем красивую словесность. Показывая свою типа продвинутость делают блевотную солянку из нашего могучего и пресного английского
> Кроме того, зафичатоглить её полностью не получится.
Перевод: не получится сделать задачу так чтобы её функционал можно было бы оперативно и безболезненно отключить без новых правок в коде.
Обычный сленг, не понятно что смутило.
Аня, спасибо за решительную статью! Прочитала с кайфом и одобрительными кивками, плюс просебяшными поддакиваниями.
Только сегодня с тимлидами обсуждали эту тему, и тут статейка прям вовремя.
Спасибо, заложил статью. Как раз сейчас в команде натыкаемся на проблемы, что продумывает как делать один человек, а делают другие. Регулярно какая-то часть знаний и требований теряется по ходу работы.
Подход в целом хороший, но нужно добавить условия - работает только для инхаус - процессов, требует высокой квалификации исполнителей, не подразумевает текучку... Думаю еще обязательные условия найдутся
Историю про архитектора не понял. Зачем вообще нужен весьма дорогостоящий архитектор, если на его решение можно наплевать и сделать по своему?
Если я правильно поняла, то предположение в том, что мы намеренно не стали делать так, как попросил архитектор. Это не так - мы на протяжении всей работы честно думали, что осуществляем его задумку. И наш техлид с ним регулярно встречался, задавал вопросы, обсуждал дизайн решения. При этом все равно были не учтены ряд ключевых идей, которые были важны для архитектора. Мы сделали что-то похожее на то, что хотел архитектор. Но этого было недостаточно для того, чтобы решение было действительно тем, что ему нужно.
Ответ на вопрос "В чем же роль архитектора или техлида в таком подходе?" нетривиальный и заслуживает отдельной статьи. Возможно, напишу её в будущем. Когда статья выйдет, скину её сюда и буду рада продолжить обсуждения в комментах под ней!
Встречался только техлид? Вопросы и решения, принятые на встречах, не записывались? Тогда получилась детская игра "испорченный телефон". Впрочем, если архитектор не заинтересован в деталях реализации его проекта, то так обычно и получается.
Это точно был в том числе и испорченый телефон для команды, когда архитектор решал за лида, а лид был инструментом реализации идей архитектора. Мне кажется, что это одна из болезней решений спускаемых сверху.
Мое мнение, что в нашем случае архитектор, когда стал решать за команду как ей код писать, напоролся на две проблемы. Проблема 1: другому человеку свои мозги не пересадишь. Проблема 2: когда делаешь что-то реально сложное, ты можешь не учесть всего в самом начале, и итоговое решение может сильно меняться исходя из той информации, которую ты получаешь начав что-то делать.
Добавлю, что для уменьшения вероятности второй проблемы можно использовать подход с прототипированием.
У вас были какие-то случаи из рабочей практики, в которых стреляли такие проблемы?
Мне кажется, что это одна из болезней решений спускаемых сверху.
Это болезнь называется микроменеджмент. Когда вместо того, чтобы поставить задачу с точки зрения бизнеса (т.е. какой функционал нужен для клиента, и какие требования к скорости/масштабируемости) и спрашивать её также, начинают говорить "здесь такую табличку в базе создай", "тут такую библиотеку добавь".
уменьшения вероятности второй проблемы можно использовать подход с прототипированием.
По опыту, так себе помогает -- прототип имеет меньшую сложность, меньший масштаб и так далее. Те на то, чтобы "учесть всё" в случаях, где прототип имеет смысл -- на это архитектора хватает. А вот всякие граничные кейсы, огромные объемы данных там где их не ждали, ну и вообще вся лабуда из реальной жизни -- всплывают после реализации, у реальных клиентов.
А, ну и конечно половина заложенных мудрых фич и возможностей расширения оказываются не востребованы, отягощая дизайн сложностью там, где это не нужно.
Возможно, у меня просто хорошего архитектора не было. Ну.. таки да, не было.
А статью ждём
Да уж, кажется очевидные вещи, а нужно об этом рассказывать и доказывать.
Нет ничего хуже, когда дали задачу, а кто-то рядом, кто за результат не несет никакой ответственности, стоит и умничает как надо делать. А ты знаешь, что предлагаемое решение - полная хрень, но спрашивать по итогу будут с того, кто писал код. Я в таких ситуациях обычно говорю, что если такой умный (а в половине случаев это идет со словами «задача то легкая совсем») - бери и делай сам.
Впрочем, есть такой тип людей, которым бесполезно что-либо объяснять. По этому иногда решением является просто смена работы.
Решает тот кто говнокодит
Тема трансфера ответственности на ЛПРа не раскрыта.
Почти любой менеджер, приняв "волевое решение релизить вот это 31.12" в случае факапа "несёт ответственность" силами команды, потому что сам чинить не полезет, а будет лежать под ёлкой, пытаясь приземлить вертолеты.
Даже если у лпр отобрали премию, и ему будет обидно настолько, что машину он обновит на год позже, все равно разгребать дерьмо будет не он.
Никакой тим, тех или любой другой лид не может за это отвечать, кроме самого человека.
Частное мнения: Какой же я ЛИД, если не отвечаю за свою ТИМ.
Хотя и "где ты ничего не можешь, там ты не должен ничего хотеть" не всегда и не для всех очевидно
Очень крутая статья! Ровно такого же подхода придерживался на работе, и до последнего не изменяя ему)
Перед тем как дать задачу команде, спрашивал, все ли ок. Если хоть капля сомнений появляется, сразу начинаем копать, что именно не нравится и так далее. В итоге чаще всего убираем лишнее, либо даём больше ресурсов на разработку. При этом команда понимает, что в случае багов именно они несут ответственность, поэтому всегда стараются сделать так, чтобы потом 10 раз не возвращаться. Кажется, что работаем медленно, но фичи в любом случае появляются и сервис при этом очень стабильно работает. И клиенты довольны, и команда довольна)
Весёлый момент из жизни: программист непременно отключил одну из фич на бекенде и никому не сказал. Через три недели выяснилось, что это никому не нужно, ведь ни один клиент даже не упомянул о сломанной странице. В итоге приняли решение удалить, чтобы не поддерживать мертвый кусок сервиса
Эх молодость... я тоже был молод и пытался переделать этот мир, был РП, начальником отдела, теперь я старый, лысый программист с кучей хронических болячек, нажитых в борьбе с дураками. Удачи вам, м.б. у вас получится что то хорошее. Я в конце концов пришёл к выводу, что лучшее решение - это отвечать только за себя.
Решительность в IT: решает тот, кто делает