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

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

Согласен с теми, кто предлагает в вашем случае контролировать не процесс, а результат.
Дополню конкретным подходом, испытанным с удаленными работниками (краткая основа):
1) Устанавливаете испытательный срок и пониженную почасовую ставку на этот период. Это обычная практика для найма.
2) Каждой задаче даете оценку объема работ. Желательно, чтобы все оценки делал один человек. Сотрудник должен знать оценки.
3) В течение месяца вы просто рассчитываете соотношение плановых трудозатрат к фактическим, заявленным сотрудником. Получаете коэффициент, который для каждого сотрудника будет свой. Обычно он меньше 100%. Выбираете для вашей компании значения: минимально приемлемое (ниже которого - увольнение) и отличное (выше которого можно дополнительно премировать).
4) В зависимости от коэффициента принимаете решение о повышении или не повышении ставки. Растет коэффициент - растет ставка. Влияние этого фактора нужно оговорить с сотрудником при найме, когда обсуждаете условия повышения. Если он не согласен - лучше сразу не брать.

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

NB: Этот показатель учитывает только стоимость и косвенно сроки. Нужно учитывать еще, как минимум, показатель качества. Это - основа. Всех деталей в двух словах не опишешь. Если есть вопросы, пишите в личку, подскажу как настроить. Есть даже готовые скрипты для выгрузки и автоматического расчета из Redmine.

NB1: Можно управлять и без цифр, на уровне "нравится, не нравится". Но с цифрами будет меньше ошибочных решений, больше прозрачности и оценка сотрудником своей ценности не расходится с вашей.

Если хотите начать с CS, пройдите Harward CS50. Он есть на русском здесь: javarush.ru/quests/QUEST_HARVARD_CS50

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

"Циклы разработки" и пр. ему не помогут.

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

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

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

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

Ну и не забывайте 2 закона, касающихся использования процентов :)
- 90% времени задачи находятся в состоянии "сделано на 90%"
- Не так трудны первые 90% проекта, как вторые 90%.

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

Reformal.ru и аналоги.

Откройте свой бизнес. Быстро уйдет технологический снобизм и появится любовь к решению бизнес-задач :)

На мой взгляд Москва и большие города в целом - места не подходящие для жизни. Сравнение здесь: 4 причины уехать из города

В оценке есть количественная сторона и есть качественная. Выпишите основные юзкейзы вашей работы. В количественной оценке можно смотреть на такие параметры, как количество кликов мышью для выполнения тех или иных юзкейзов, время, затрачиваемое на непосредственные действия с UI в каждом юзкейзе. В качественной оценке - обычный опрос удовлетворенности пользователей. Можно взять NPS. Он в данном случае будет показывать количество сторонников и противников данной системы в вашей организации.

Как вариант: любой сервис опросов с отправкой результатов на почту типа Limesurvey. Насколько я знаю, в slack можно настроить переадресацию почты. + любая напоминалка о том, что нужно пройти опрос. Напоминать регулярно может все что угодно: от будильника в телефоне до google календаря.

Redmine + плагины
Это не ERP, но то, что вам нужно сделать может.

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

В любом ВУЗе програму обучения можно скачать с сайта либо взять на факультете.

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