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

Штат нужно выбирать в следущих случаях:
a) Если предполагается окупаемое долгосрочное развитие и поддержка этого приложения. Т.е. вы уверены, что у вас есть или планируется регулярный бюджет на это. При этом у вас достаточно времени на набор команды либо команда уже есть.
b) Если одна из стратегических целей вашей компании - приобрести компетенции в разработке мобильных приложений.

Иначе, если денег мало и перспективы приложения туманны - фриланс.

Иначе - аутсорс.

Вот эту прочти.
Что касается сервисов: размести свое резюме на HH и LinkedIn. Это на 90% откроет тебя потенциальным работодателям, которые активно ищут кадры.
Поиск работодателя - делается не с помощью сервисов. Если хочешь осознанно строить карьеру, а не тыкаться в слепую куда занесет, вот правильная стратегия:
1) Выбираешь компанию и должность, в которой ты хотел бы работать в будущем.
2) Выясняешь каких навыков и знаний тебе не хватает для того, чтобы попасть туда.
3) Ищешь компанию, где ты сможешь получить необходимый опыт.
4) Повторяешь п.2 и п.3, пока не выстроишь цепочку до компании, куда тебя готовы взять сейчас.
5) Идешь по цепочке к своей цели.

Если говорить не о командных, а о персональных KPI программистов, то для переменной части з.п. я применяю персональный фокус-фактор и показатель качества отладки + оценка руководителя. Если интересно - обращайтесь в личку.

Если речь идет об экономии времени на вливании новых людей в проект, то все, что вам нужно, это:
1) Выяснить, отсутствие какой инфрмации приводит к наибольшим трудозатратам нового саппортера
2) Описать нужную информацию при условии, что время, потраченное на описание, будет стоить меньше чем время, которое в противном случае будет потрачено на то, чтобы самостоятельно разобраться и выпытать это у коллег (с учетом времени коллег).

google

Две мысли для расширения понимания конкуренции:
1) В современном мире за одни и те же деньги потребителя конкурируют все, кто что-либо продает. Вне зависимости от отраслей и ниш.
2) Конкуренты в одной нише могут стать и партнерами при желании.

Совет:
Разруливать здесь нечего. Вне зависимости от отрасли, не распространяйте информацию, полученную от своих клиентов. Если вы построили с ними надежные доверительные отношения, то не будет иметь значения, узнают ли они друг о друге. А если доверия нет, то рано или поздно вы так или иначе потеряете клиента. Т.е. суть не в том, знают ли они друг о друге, а в том, доверяют ли они вам. Стройте отношения, укрепляйте доверие и не будете бояться подобных вопросов.

Насколько я понимаю, в вашей ситуации такое совмещение - это стратегия постепенного перехода на фриланс, когда страшно "вдруг сначала будет мало заказов".
В таком случае, почти по Тиму Фэррису:
1) Переведитесь с работы в офисе на удаленку
2) Сократите потери во времени и начните совмещать
3) Когда поток заказов станет стабильным и альтернативный доход от часа фриланса будет выше чем от часа в найме - увольняйтесь из найма

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

Если же заказчик непременно хочет fixed price, поговорите с ним, поймите текущую картинку в его голове и главное - цели, для которых строится "машина" или боли, которые она должна снять. Она нужна потому, что у соседа такая? Для того, чтобы съэкономить время? Для того, чтобы преодолевать бездорожье? Чтобы произвести впечатление? Чтобы вложить деньги? и т.п.
После этого предложите свой вариант "машины". Объемы цены и сроки рассчитывайте исходя из предлагаемого вами варианта и явно это укажите в коммерческом предложении. Там же оговорите свои предположения относительно готовности их кода к интеграции. "Стоимость проекта рассчитана в предположении, что .... 1)... 2).. 3)... После анализа исходного кода заказчика (а так же при выборе заказчиком другой модели автомобиля или комплектации) стоимость проекта может быть изменена."

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

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

Если у вас нет плана, то причина не в том, что нет инструмента. Инструментов полно и дело не в их выборе. Дело в том, что у вас (и судя по всему у вашей команды) нет навыков проектной работы, включая планирования проектов.
У вас есть выбор: a) Учиться этому "методом тыка". Это больно, дорого, долго и не факт, что хорошо научитесь. b) Взять в команду опытных людей, которые вас научат. Это - лучший вариант. с) Если в команду вы привлечь таких людей не сможете, то хотя бы поучитесь у них. Есть множество курсов. Выбирайте практиков.

1) Оценка как правило основывается на прежнем опыте. Задачи с новой технологией и новой базой не имеют достаточной основы для оценки. Желательно сначала создать исследовательскую задачу. Результатом этой задачи должна стать оценка. Исследовательскую задачу тоже не просто оценить, но ее можно ограничить. Например: "Дать оценку с той точностью, которую можно получить, потратив 16 часов на исследование." В любом случае - это будет точнее, чем оценка "навскидку". Если задачу будет оценивать 1 человек, а не покером, то для уточнения используйте оценку по 3 точкам.
2) 50 часов - это немного больше человеко/недели. У вас спринт - меньше недели? Если все же задача выходит за границы спринта, ее нужно дробить на части (желательно не больше 3-4 человеко/дней) и распределять эти новые задачи по следующим спринтам в общем порядке. Еще один вариант - подумать можно ли получить ту же бизнес-ценность другим, менее затратным путем.
3) В скраме вместо гантта используют диаграмму сгорания. Ее двигать не надо, нужно просто дорисовывать каждый день. Кстати, при использовании гантта, его вручную двигать не нужно, если есть регулярное обновление статусов от разработчиков (например в MS Project).

Комментарий к постскриптуму. Напоминает анекдот "Что тут думать? Прыгать надо!"
Каждый час, выделенный тобой на обучение, высвободит тебе и команде на порядок больше времени, теряемого впустую, в каждом проекте. Добавь к этому стоимость ошибок и еще раз подумай. Желая съэкономить время, ты на самом деле, выбрал самый времязатратный, дорогой и долгий режим развития.

1) На практике это означает a) Людей в команду желательно подбирать более универсальных, владеющих разными технологиями и без амбиций типа "яжпрограммист, я не буду тестить". b) Если выбирать не приходится и вам достались узкие специалисты и при этом команда постоянная, то занимайтесь ее развитием, расширяя их компетенции. Это долго, но стоит того. с) Если специалисты узкие и даны на короткое время, тогда обходитесь без кроссфункциональности. Это не догма, как и все остальное в скраме.
2) В planing poker не могут участвовать 2 человека. Участвует вся команда. Кроме того на практике джуниор обычно не спорит с сеньором, а прислушивается к нему. По времени планирование спринта - ограничено. (мах 8 часов для больших и сложных спринтов) Скрам-мастер должен следить за тем, чтобы обсуждение шло конструктивно и не буксовало. Если кто-то уперся рогом в землю, не может убедить других и не слушает их аргументы - это не командное поведение. А команда - это основа agile. С ним нужно проводить воспитательную работу. Если это регулярно - возникает вопрос, действительно ли его место в этой команде.
3) Все необходимые виды тестирования должны проходить в рамках спринта. Желательно использовать Continuous Integration и тесты, включая нагрузочные гонять регулярно. Разработчики, реализуя user stories должны думать о производительности, как и о многом другом. Разумеется, требования к производительности должны быть им озвучены.
4) Это не скрам, а одна из практик экстремального программирования. Применял в компании SiberLogic. В случаях, когда было критически важно, несмотря на затраты, быстро и качественно запилить задачу за часы.
5) Коммуникацию с заказчиком в скраме обычно осуществляет продакт. Он же и отвечает перед ним. Команда отвечает перед продактом. На практике в некоторых компаниях перед заказчиком отвечает ПМ, который находится снаружи скрам-команды.
6) За найм и увольнение отвечают те же люди, что и без скрама. Это может быть директор или HR. Иногда этим занимаются ПМы. Однако, скрам-команда может "вытолкнуть" человека, если он в нее не вписывается. Если разговоры по душам не помогают, то человека перемещают в другую команду или в другую компанию :)

По книжкам скрам не внедряется. Если будут еще вопросы, пишите в личку.

dreel.ru вроде это умеет

Если число участников проектов в перспективе планируется больше двух, то есть смысл смотреть не на персональные органайзеры, а на системы управления проектами. Гугль вам в помощь.

Посмотрите планфикс. Он умеет с Viber.

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