Андрей Плетенев

Все давно уже ускорено и автоматизировано. Эволюция сайтостроения прошла уже 3 стадии: 1) Ручное программирование 2) Использование фреймворков и шаблонов 3) Конструкторы сайтов.
Ответ на ваш запрос - переходите на 3 уровень. Минимум времени и нудности.

Есть филиалы и дочки, а есть независимые конторы, которые занимаются заказной разработкой. Как в любом бизнесе, самые трудные клиенты - первые. Те, кого я знаю начинали с личного знакомства с потенциальным заказчиком. Бывает это по разному: знакомства на выставках, конференциях, во время отпуска за границей, знакомые, уехавшие за границу. Если все сделаешь отлично, то клиент становится постоянным и подкидывает работу. Потом по рекомендациям приходят другие клиенты.
В целом аутсорс заказной разработки в Северной америке и Европе довольно востребован из за дешевизны и неплохого качества российской разработки. Но нужно иметь в виду, что конкуренцию россиянам в этом плане составляют программисты Белоруссии, Украины и Индии.

https://www.google.com/calendar

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

Никто вас не попрет за это. Учиться не зазорно, а необходимо.
Если будете прятаться, то потратите больше времени на то, чтобы найти решение и сделать. Вот это снизит вашу оценку.

Поговорите с каждым ПМ'ом один на один. Без гонора и амбиций, а по человечески. Можете даже пивка попить или чаю. Нормальный ПМ сам должен был бы это сделать, видя, что вы раздражены. Но, возможно, вы скрываете свои чувства или Пм'ы еще неопытные. Исходите из того, что вы с ними делаете одно дело и должны помогать друг другу. Расскажите ему, что по-вашему, мешает вашей совместной продуктивной работе и предложите свои варианты взаимодействия. Оперируйте фактами, а не эмоциями, обсуждайте действия, а не личности. Нормальный ПМ нормально к этому отнесется и объяснит почему действует именно так или изменит свое поведение. Если не удастся прийти к общему решению, идите к вышестоящему руководству. После этого на вас снизойдет просветление, либо вы перестанете работать вместе.

Постоянно (условно) в штате должно быть столько людей, сколько вы можете загрузить (и соответственно прокормить) на регулярной основе. Все остальные перепады спроса регулируйте фрилансерами и аутсорс-командами.
Если используете redmine и хотите готовый автоматический расчет через Excel

• % загрузки ресурсов по времени
  
• дат высвобождения каждого сотрудника
  
• дат готовности к старту новых проектов
  

обращайтесь.

Все, кроме п.4 можно настроить полностью автоматически (без тыкания кнопок на таймерах) с помощью RescueTime.
Для п.4 можно использовать любую напоминалку/будильник/sheduler/таймер, включая аппаратные.

Для помощи в поисках давно придумали гугл. Ключевые слова "бесплатный helpdesk".

Если речь идет о напоминаниях к событиям, жестко привязанным ко времени - обычный Google Calendar, который по определению есть в каждом андроиде.
А если нужны напоминания типа "Напомни мне через 15 мин. об этой задаче", то любой облачный тудушник типа doit.im, MLO, todoist и т.п.

Никого не собираюсь переубеждать. Пишу, только потому, что вы попросили совета.
Мой совет такой: Сколько бы вам не платили, здоровье - это самая последняя вещь, которую стоит продавать. Правда, понимаешь это не сразу :) Сначала вы обмениваете здоровье на деньги, потому, что здоровья много, а денег - мало. Это кажется разумным. Потом, здоровья начинает не хватать и вы начинаете обменивать все больше денег обратно на здоровье. Ваши прошлые решения уже не кажутся вам такими разумными. Потом, вы понимаете, что деньги вообще не имеют большого значения, если здоровья нет.
Весь вопрос только в том, когда наступит ваше "потом". Есть определенная точка невозврата, когда вернуть потерянное здоровье нельзя, даже обменивая его на очень большие деньги.

C 1 по 5 покрывает MLO. Хотя это все же персональный органайзер, однако расшаривать проекты там можно.
С 1 по 6 - менеджеры проектов типа Redmine (для Андроид клиента, тэгов и графиков/схем есть плагины).
Майндмапы в подобном софте нигде не встречал. IMHO модный, но не самый лучший способ структурирования информации.

1) и 3) Решается наймом людей на техподдержку. Ценник на разработку это не увеличивает. Поддержку нужно продавать отдельно.
2) Предлагайте 2 опции поддержки: a) Взаимодействие через тикетную систему e-mail-Redmine (как было предложено выше) b) "Персональный" менеджер и созвон/переписка через него. Цена (а) - ниже, (b) - дороже. И никого уговаривать не нужно. В первом случае - все автоматизировано, а во втором - у вас есть деньги для оплаты саппортеров.

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

1. Способ принятия решений это не догма, как и все в скраме. Его выбирает команда. Можете использовать a) классический подход - консенсус (демократично, но медленно), b) решать большинством (менее демократично, но быстро), c) доверить оценку тем, кто наиболее вероятно будет делать задачу. В т.ч. это можно делать за рамками скрам-митинга, хотя и не рекомендуется. Если в случае b) голоса разделились поровну, то можете либо продлить обсуждение, пока один человек не изменит мнение, либо всегда использовать правило выбора меньшей (вызов) или большей (запас) оценки.
2. Судя по описанию, проблема в том, что команда пока не вполне зрелая для agile. Среди ценностей гибкой разработки важную роль играют взаимное доверие и самоорганизация. Если люди обижаются, когда другие не соглашаются с их мнением, это означает, что они ставят свое эго выше интересов команды. Так бывает в командах, которые стали командой просто по назначению начальства. Берут сам фреймворк, процедуры, но никто не думает о главных принципах. Внедрение ценностей скрам - дело скрам-мастера. Объяснять, воспитывать, в первую очередь собственным примером. Как только появится несколько лидеров, которые проникнутся - остальные подтянутся. Дальше - будет легче. Новички будут адаптироваться наблюдая за остальными.
Чтобы люди не пытались "попасть в ту же цифру" используйте planning poker. А цель обсуждения - не "отстаивать свое мнение", а дать команде больше информации для принятия взвешенного решения.

По первой проблеме советую выяснить, что именно вызывает плохую реакцию заказчиков на ваше CV.
Второй проблемы вообще не вижу. Если речь не идет об инвестировании в собственные разработки, то проекты будете делать те, по которым на ваше CV будет хорошая реакция. В отсутствие заказов - изучайте, то что нравится и дополняйте CV.

Помимо всевозможных WIKI есть еще интересный инструмент: Rizzoma. Он полезен, если общение происходит в чатах. Там есть встроенные инструменты структурирования, с помощью которых любое обсуждение не теряется, а превращается в часть вашей корпоративной базы знаний. Нужно лишь следовать некоторым правилам. В результате вы имеете самонаращиваемую knowledge base в которой есть структура, работает поиск по тэгам, ключевым словам и т. п.
Отличие от обычных WIKI:
1) Чтобы в WIKI что-то появилось, нужно специально садиться и писать топик. Обычно трудно мотивировать людей это делать. Поэтому зачастую в компаниях WIKI неактуальна и мало пополняется. В Rizzoma это происходит естественно, т.к. она является инструментом общения.
2) В каждый топик может одновременно писать несколько человек. С одной стороны их комментарии видны прямо в контексте, а с другой стороны видно авторство каждого.
3) Не надо устанавливать и платить :)