не пиков нескольько было: "ты кто UX дизайнер - иди отсюда, а ты ? QA иди отсюда. техписателя с собой забери. Аналитик иди сюда щас за продактом будешь записывать че ему надо. Продакт у тебя 3 предложения чего те надо. говори"

вообщем сначала делаешь буквально на коленке то чего вот прям очень надо надо - все остальное в топку... а уже потом когда получишь фидбек только тогда станет действительно понятно а чего надо

+

а иначе будет "ой чет дорого так" "ой а тут наверное надо не так" "ой а маркетинг сказал вот сяк"

Ну этой какой-то мегадорогой способ прокрастинации)

😎Александр Поломодов, руководитель управления разработки цифровых экосистем в Tinkoff, выскажет на TeamLead Conf 2021 альтернативную точку зрения на проблемы управления с точки зрения инженерных метафор.

Часто получается так, что тимлидом в команде становится самый прокачанный разработчик. Зачастую этот разработчик хорош в hard skill’ах, но менеджментом до этого не занимался. В своем докладе Александр расскажет, как принципы SOLID могут помочь технарю понять базовые правила менеджмента 👉 bit.ly/2OOJmac

✅TeamLead Conf 2021 совсем скоро – 29 и 30 апреля. Купить билеты на нашем сайте 👉 teamleadconf.ru/moscow/2021

> с точки зрения инженерных метафор.

я бы послушала про правовые аспекты работы с территории других стран (вроде есть какие-то проблемы с налогами и чем-то там ещё)

Спасибо

Посмотрел видео, спасибо, ценное) Но опять таки - мне не понятно как разработчик может думать о ожиданиях заказчика. Это какой-то супермен-универсал получается. Для разработчика заказчик - тот кто ставит ему задачу. И он должен проверять соответствие поставленной ему задачи. Ну и мыслить на уровень шире - классика что бэкендер не задумывается что с его API будет фронт работать и т.д.)

Пару раз в чатах мелькало от @dphil
что системный аналитик это антипаттерн, который говорит о том что коммуникация между разработкой и бизнесом нарушена.
 
Это не прямая цитата, а то как я понял. Мог понять неверно.

Дополню тут, что мне непонятно как можно наладить работу при которой разработчик более-менее заменяем и при этом взаимодействует с бизнесом напрямую.

Смотрю просто речь зашла за то, что разработчик должен смотреть глазами бизнеса.)

либо аккаунт подставной и мы вместе работаем, либо действительно дикое сходство с коллегой :)
Методы похожи =)

Это не мой метод :)

Смотря что вы понимаете под словом разработчик. Не уж то вы подумали, что это прогер, который сидит кодит? Речь шла о том, что есть компания разработчик и есть компания заказчик и о том как им взаимодействовать. В данном контексте, разработчик - компания.

Мож это инхаус.)

Заказчик в 90% случаев представления не имеет о том, что он хочет получить. И тут вам нужен бизнес аналитик, который по тех требованиям заказчика напишет ТЗ

в 90% случаев бизнес аналитик пишет по фактическому результату)

смайлик не в ту сторону :(

Зря зп получает, такой аналитик