Nividimka

Все проще!
Заходим regedit
Открываем ветку "Компьютер\HKEY_USERS\.DEFAULT\Keyboard Layout\Preload"
Там должно быть столько языков ввода сколько вам надо - все лишние строки удаляем.

Эти две недели "Живите вместе" с прежним разрабом.

1) Пусть расскажет архитектуру, надет все обрывки по постановке ТЗ и выполнению, детально их покажет и отсортирует.

2) Пройдите с ним по типовым кейсам поддержки / доработки. На второй неделе садитесь сами выполнять все заявки по системе, которые приходят на разраба (он чтобы был рядом как тьютор)

3) Фиксируй для себя сразу, что было не понятно. И спрашивай

4) Попробуй договориться (в идеале через руководство) или лично со старым разрабом, что можете обращаться к нему эпизодически за советом ближайшие несколько месяцев.

5) Пусть старожил расскажет бытовые / политические / экономические особенности этого работодателя.
У тебя идет испытательный срок? Прекрасно! В случае Пушного зверька на горизонте имеешь право уйти одним днем.

6) Если время позволяет и ресурс есть, то пусть аналитики или этот разраб (если он Алл-инклюзив) садаться и ночами пишут доки по системе. Со стороны работодателя будет корректно предложить за это премию / бонус / договор ГПХ после увольнения разраба.

Смс уже никто не шлёт.
Все в телеграмме.
Это бесплатно. Удобно. Легко реализовать.

Трекинг времени в основном вводят по трем причинам:

1. Недоверие к сотруднику -> необходимость контроля
   
2. Желание оптимизировать время -> использовать время сотрудников более рационально
   
3. Зарплата зависит от потраченного времени
   

Вопрос в том, по какой причине вводят трекинг?
Первое - если причина в управлении, то это не лечится; если в вас, то вы сами дали повод вас чекать.
Второе - отличная идея.
Третья - тоже хорошо :-)

Я трекаю все, вплоть до совещаний. Минимальный шаг трека - 15 минут. Все, что меньше, объединяю в минимальный трек.
На мой взгляд, трекинг стоит делать в любом случае. Как минимум, анализ собственных треков позволяет увидеть дыры во времени. Как максимум - вы увеличите свою продуктивность раза так в 2.

Удачи :)

Законченный, якобы, проект с кривым кодом(архитектурой) - это как дом с кривым фундаментом, зачастую у него не то что низкая, у него отрицательная стоимость. То есть с нуля действительно дешевле переписать будет. Но как избежать повтора ситуации (когда вроде бы все готово, но по мелочам ничего не работает)? Для этого нужно заказчику или руководителю проекта добиватся законченных изолированных микро-решений на каждом участке (на каждой форме - диалоге - старнице). Нужно не боятся и менять первоначальные решения (просить дополнять или изменять функционалность) и смотреть как програмист будет подстраиватся под изменившиеся бизнес-требования (это реальные ситуации которые будут возникать в промышленном использовании продукта от пользователей). Если программист застревает - это и есть реальная скорость разработки проекта и признаки что проект не будет доведен до конца и выведен в эксплуатацию. А то что заказчику. там "архитекторы" накидывают код, и говорят что там все сделано и надо только дописать - это разработка нулевая или даже с минусовой стоимостью.

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

Ну начинается проект все ок. Программист пишет - пишет вроде бы начинают появляться рабочие экраны или работающий функционал, но он не следит за чистотой кода, игнорит или не знает рекомендованные стайлгайды, стиль кода постоянно меняется, все накручивается на базовых примитивах типа for-if, нарушаются декомпозиционные сущности, рефакторинг собственного кода (для дальнейшего облегчения понимания) отсутствует (главное чтоб работал). Постоянно его костылит. И код превращается в кучу крепко завязанного, запутанного говна. Попытки внести фиксы или дополнительный функционал в такой код приводят к ещё большим проблемам. Причем снаружи - это действительно выглядит как будто что то не работает по мелочам. Но поддержка и развитие такого проекта останавливается и автору коду уже невмоготу с ним работать, потому что петля этого монолита уже крепко затянута. И человек либо тянет время и просит нанять ещё разработчиков, либо просто уходит на "лучший офер". Заказчик думает что там осталось совсем чуть чуть. И любая попытка погрузить нового программиста в этот проект проваливается.

Объясняйте заказчику, что код очень сильно запутан. Приводите упрощенные примеры запутанности и приводите примеры их решения. Воспринимайте этот запутанный проект - как челендж для себя. Думайте о том, что если вы его распутаете, поблочно перепишете и разложите все по полочкам, ваша стоимость увеличится в разы как специалиста. Оцените свои силы, научитесь жёсткому параллельному рефакторингу вместе с текущими задачами, декомпозируйте код на части, изолируйте части кода. Заказчику не произносите слово "рефакторинг". А писать с нуля - это не вариант. Вы просто протянете время и не факт, что не придёте к тому же, что сделал предыдущий разработчик. И потом свалите. Лучше научитесь плавно метаморфизировать проект при этом выполняя текущие задачи.

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

И самый интересный финт, получается такой, что в глазах заказчика автор(источник проблем и говнокода) будет выглядеть как некий профессионал с гениальным кодом и архитектурой, код которого никто понять и поддерживать не может, потому что якобы все приходящие на проект не достаточно квалифицированы.

Да... работа такая у программиста запутанное(сложное) делать понятным(простым), а не наоборот.

Имеем 4 колонки на kanban-доске:

1. Список заданий
   
2. В процессе
   
3. На проверке
   
4. Исполнено
   

Теперь о каждом чуть более детально.

Список задач, он же backlog - список того, что вообще надо сделать. Сортируется это дело по приоритетам, т.е. самая верхня задача самая важная, самая нижняя - самая не важная. Отдельно отмечу, что только в данный момент времени. Отметок "Важная", "Важная 1", "Важная 2", "Срочная", "Горящая" и т.п. быть не должно. Если задача есть в этом списке, значит она важна для команды. Ее исполнение необходимо для нормальной работы команды. Акцентирую Ваше внимание, что именно в данный момент. Как тимлид Вы можете сделать только одну доработку в этой колонке - присвоить цвет каждому подчиненному. Например, Иван берет только синие задачи, Николай только желтые и т.п. Срочнось задач в компетенцию тимлида не входит, это зона ответственности менеджмента.

В процессе - задачи, над которыми именно сейчас работают Ваши подчиненные. Не вообще работают, а вот конкретно в данный момент, когда Вы открывайте доску и смотрите на нее, Ваш человек сидит в IDE и пишет/отлаживает код. Колонка обязана иметь лимит. Все книжки рекомендуют начинать с 2n - 1, где N - количество людей в команде, а минус 1 потому что кто-то может с чем-то застрять и ему надо будет помочь. Порядок задач в этой колонке не важен. Важно только то, сколько они там находятся. У Вас должно быть какое-то время реагирования, т.е. если задача висит там 3-й день, то нужно спросить условного Николая, что у него там за проблема и не нужно ли ему там с ней помочь. Часто, это колонка разбивается на на две: в процессе и отложено. Вторая означает, что когда исполнитель начал работу над задачей, он не нашел, скажем, доступа к хостингу или данные к FTP/cPanel, предоставленные клиентом, оказались не верными. Колонка "Отложено" требует уже реакции менеджеров в духе "Звонок клиенту". Задачи от колонки "Отложено" менеджеры должны обрабатывать, дополнять и перемещать снова в backlog. Продуктовые команды, обычно, такую колонку не используют. Разного рода digital-агенства применяют это очень часто.

На проверке - думаю, из названия понятно. Ваш подчиненный завершил задачу, Вам/Менеджерам/Клиенту надо ее проверить. В эту колонку задачи могут переносить Ваши подчиненные, но из нее переносить задачи могут только менеджеры или Вы.

Исполнего или Готово - опять же, думаю понятно. Завершенные задачи. В конце рабочей недели по наполнению этой колонки можно оценить продуктивность команды или/и продуктивность конкретного разработчика, если Вы будите использовать схему "Человек - Цвет". Карточки из этой колонки отправляются в архив в пятницу в 19:00 или когда Вы там выгоняйте всех программистов из-за мониторов. Также, в конце каждой недели, должен чиститься backlog от более не актуальных задач. Помните что я писал выше? В первой колонке у нас только важные задачи, которые необходимы именно в данный момент. Если клиент "заглох" или "слетел" - его задачи из backlog должны быть отправлены в архив, вместе с завершенными задачами в пятницу в 19:00

Отдельно отмечу, что появление задач с метками "Важное 1", "Срочное", "Очень-Очень срочное" в любой системе управления, не только scram/kanban, говорит о том, что в компании слабый менеджмент. Есть задача. Ее либо надо сделать прямо сейчас или в ближайшее время либо ее нет смысла делать совсем.

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

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

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

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

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

===================================================

Узнайте у него самого, что ему интересно делать? Может быть у него хобби какое-то есть? Пусть развивает своё хобби подсунутыми вами средствами (тот же фриланс по узкой специализации).
+ Сейчас популярны всякие видеоблогеры, а если руки и мозги есть, то я думаю и материал будет.