Вся автоматизация процессов - самописная, разработчик не справляется. Как поступить?

GAsteel

10/02/2010

2 krasnaya mechta:
Предложил технологию перехода в личку.

"Бизнес должен сохранить скорость развития и избавиться от зависимости равной одному человеку"
Вам придется выбирать - либо-либо. Либо скорость развития, либо деньги. Вам придется либо отказаться от нововведений в старой системе и просто ее поддерживать силами старого программиста (платить ему только за поддержку, а не за нововведения), пока не заработает в полный рост новая учетная система.
Либо развиваете старую систему (Вы же это имели ввиду под "скоростью развития"?)и параллельно создаете и развиваете новую систему (а это уже другие деньги, ведь старому программисту нужно платить и за нововведения).

Ответить

Figu

17/02/2010

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

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

Удалённость не мешает программисту работать! Это факт! Мешает ему его гениальный мозг, амбиции или лень.

На самом деле, программист - это обычно самое глупое существо в проекте

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

Так что не переоценивайте их значимость и не ведитесь на поводу...

Ответить

Александр Фролов
Генеральный директор, Shop2YOU

18/02/2010

Figu:

Взять нового программиста-гения в штат, постепенно он войдёт в курс дела и забыть про старого программиста-гения

А через некоторое время ситуация повторится )

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

Figu:

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

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

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

Ответить

krasnaya mechta

12/03/2010

GAsteel:

Либо скорость развития, либо деньги.

Спасибо, отчасти это действительно так. Как обычно, ищем баланс деньги-время-качество.

Figu:

Так что не переоценивайте их значимость и не ведитесь на поводу...

освежили взгляд, спасибо. а то я что то затушевался даже на последних порах.

Александр Фролов:

А через некоторое время ситуация повторится )

тоже факт. Касательно изменения организации самого процесса и подходов к разработке - тоже согласен.

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

1. принимается на работу специалист средне-высокой квалификации для дальнейших работ по проекту. Благо, рынок не пуст

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

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

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

при этом:
- затраты если и увеличиваются, то не особо сильно (как бы тратимся только на время потраченое специалистами. Первый - фул тайм, второй - сдельная по часам (это тот который волк)

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

- запас "прочности" системы увеличивается за счет новых принципов развития

ну и параллельно ведутся рассуждения о кисельных берегах на тему "а не поставить ли что то готовое"

Вот примерно так.
Покритикуйте, плиз...где я что упустил пока Вы мне помогали советами
Всем отличного настроения!

Ответить