имею в виду в ответах)

я решила опросить сразу две стороны и понять, что и кого болит

Я не думаю что вы общих ответов тут дождетесь. Проблемы всегда сложнее и индивидуальнее. Иначе надо писать общую научную статью на предмет анализа работы современных компаний, а их там уже библиотека написана.

Не, ну есть жанр охотничьих историй

и еще библиотека статей чтобы понять предыдущую библиотеку

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

NDA

а вот мне и не нужны общие ответы. мне как раз нужны истории каждого отдельного человека

Вы из этих частностей ничего не достанете, но получете вероятно мнимую уверенность и не дай бог начнете на базе нее что-то генерировать.

поэтому и вопрос мой был таким обобщенным

Блин, ну общие ответы есть в статьях, книжках и нытье на хабре (регулярно):)

Над этими проблемами бьются лучшие умы менеджмента, чтобы хоть как-то это внятно собрать и наметить успешные пути. И у большинства они получаются весьма уникальные. Потому что категории проблем конечно общие, но люди и условия - разные.

согласна с вами

хорошо, а если идти от обратного. что нужно знать начинающему менеджеру? и с чего ему стоит начать?

>фаундер нанимает разработчика, при этом не понимая всех технических нюансов. Разработчик делает фичу, фаундер не смог отследить, хорошо он ее сделал или нет.

В этой цепочке сломано все и я очень надеюсь, что так уже не бывает.
Разработчика должен нанимать не фаундер, а CTO, если у фаундера нет необходимых скиллов.
Отслеживать хорошо или нет должен QA, хотя бы один тестер должен быть, как минимум чтобы не замыленным глазом смотреть.

>Фаундер нанимает еще одного разработчика. Так у него появляется их штук 6.
А нужно было нанять одного тестера и одного техдира

>менеджер поставил тз. разработчик его либо не допонял, либо тз было сформировано плохо. не уточнил детали и сделал фичу, а она работает не так, как надо.

Разработчик не должен уточнять детали, разработчик, это грубо говоря, крановщик на стройке (простите, парни). Он видит что в ТЗ "поднять балку на шестой этаж" и поднимает. О том что балку нужно поставить определенным образом, должен писать заказчик.

С работы под управлением более опытных людей

Я не тролю, но - с понимания зачем это вообще вам нужно. Как правило, если возникает вопрос "с чего начать" - значит начинать пока рано.

А не с надуманных статей в интернете

охохохо

+