Здравствуйте!

Помогите, пожалуйста, разработать систему расчета заработной платы для программистов IT-отдела.

Предлагается (руководством) 2 варианта. В том и другом варианте предварительно составляется план работ на месяц.

1. Фиксированный оклад у каждого сотрудника (в день).

В качестве стимулятора к работе предлагается:

1. квартальная премия в 15% от оклада за регулярное выполнение плана, 

2. снижение на 10% зарплаты при срыве ежемесячного плана и увеличение штрафа в случае рецидива.

2. Фиксированная оплата рабочего часа

Если месячный план выполняется сотрудником целиком, то он получает планируемую зарплату вне зависимости от фактически затраченного времени. Т. е., если сотрудник не укладывается в плановые часы, то он работает вечером или в выходные (за свой счет). А если выполняет план, то либо выполняет другую задачу (и по итогам месяца получает больше), либо отдыхает. При выполнении плана в течение квартала выплачивается премия в 15% от среднемесячной зарплаты.

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

Ни в том, ни в другом нет стимуляции к инициативам (например, предложить реализовать ту или иную функцию, ранее не предусмотренную и т. п.)

Ни в том, ни в другом варианте не учитывается срыв плана работы одного сотрудника по вине другого (смежника).

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

1. либо путем наглого обмана (говорить, что на выполнение задачи потребуется 3 дня вместо одного),

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

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

Спасибо за ответ.

А. Про ошибки

1. С исправлением собственных ошибок программиста понятно - работа не оплачивается.

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

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

3. Что представляет собой стандарт? Это определенный алгоритм и/или набор правил, по которым происходит тестирование/документирование. Есть ли правила его создания? 

В. По инициативе

Говоря об инициативе, я имел ввиду именно креативный подход к работе. Ведь одну и ту же работу можно выполнить по-разному.

Примеры.

1. После создания новых разделов на веб-странице, оказалось, что в разных частях страницы отступы между строчками разные. Теоретически работа выполнена. Фактически - требуется небольшая доработка, которая замечается через некоторое время на этапе тестирования.

2. Добавляется новая страница сайта. Она должна быть оформлена в том же стиле, что все остальные. Можно донимать дизайнера по поводу каждой "закорючки", а можно самому все сделать красиво.

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

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

С. О смежниках

Как работа одного сотрудника может повлиять на работу другого:

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

2. Один из программистов начинает изменять настройки на сервере - в этот момент (и на неопределенное время, например 3-4 часа) работа у всех останавливается.

3. По плану один сотрудник должен закончить работу над основным ядром программы за 4 дня, потом над проектом начнут работать несколько человек. Проходит 12 дней. В результате "простой" 8 дней у остальных. Причем сотрудник в большей степени не виноват, он подошел креативно, сделал множество улучшений в первоначально задумывавшемся ядре и можно сказать заслуживает премии. (Это реальный пример, но задержка может быть и не такой критичной, например полдня).

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

Д. О нормах времени

Теоретически все понятно и красиво. Практически - натыкаешься на вопросы без ответов.

Сначала пример уже выполненной работы (постараюсь без сложных терминов).

Задание: сделать в веб-сервере поддержку соединения по защищенному протоколу.

Как виделся план работы до выполнения :

1. прочитать документацию
2. подключить модуль шифрования трафика (заранее известно, что нужен модуль)
3. сделать настройки сервера (неизвестно еще какие)
4. разобраться с выдачей сертификатов безопасности (известно, что он необходим, но как "это" работает неизвестно)

Что получилось на самом деле:

1-й день:

1. прочитал документацию
2. обнаружил, что существует 2 альтернативных модуля
3. начал искать информацию о сравнении двух модулей
4. обнаружил, что в новой версии сервера один из модулей уже встроен и решил использовать его
5. установил новую версию сервера с этим модулем
6. проверил работоспособность существующих сайтов на новом сервере
7. оказалось, что не работает система авторизации на одном из сайтов

2-й день:

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

3-й день:

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

4-й день:

1. перевод сайтов на новый сервер

Видно, что появилась никак не запланированная ветвь с новой версией сервера.

Теперь реальная задача.

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

Задачу смогли разбить всего на 4 этапа:

1. установить сервер контроля версий
2. разобраться с порядком работы, сделать соответствующие настройки
3. установить каждому программисту приложение
4. научить каждого пользоваться.

Дальнейшее дробление "не идет", т. е. программист не может внятно ответить из каких операций состоит тот или иной этап. Как его вывести из "оцепенения"?

Уважаемые Коллеги!!

Мне тоже хотелось бы присоединиться к данному обсуждению.

А. Относительно ошибок.

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

1. Ознакомление с проблемной ситуации. Часто Заказчик не может четко сформулировать ТЗ. И излагает свои желания в стиле: "Хочу то-то" или "Хочу, чтоб было клево".
2. Постановка задачи.
3. Составление плана работ. Очень хороший вариант предложен выше. Хотя, увы, к этом прибегают не все и не всегда.
4. Изучение предметной области.
5. Разработка модели (на основе изученных данных). Выделение абстракций, классов и т.п.
6. Написание кода. Как правило, первоначальный код пишется с ошибками. Ошибки могут быть двух видов:
1. Просто опечатки. Выявляются на стадии компиляции.
2. Более сложные ошибки. Выявляются на стадии выполнения. Что-то не появляется, программа виснет при определенных условиях.
3. Как правило, большинство из этих ошибок или даже все программист может устранить самостоятельно. Это зависит от тщательности его работы.
7. Тестирование программы программистом. Устранение допущенных ошиок.
8. Сдача написанного кода.

Мне бы хотелось заострить внимание на том, что есть два вида ошибок:

1. Ошибки до сдачи написанного кода. Эти ошибки практически появляются всегда. Основные причины:
1. Не до конца правильное представление о предметной области, какой-нибудь библиотеки и т.п. Ошибка как бы корректирует это представление.
2. Просто опечатки.
2. Ошибки после сдачи написанного кода.

Программист, который качественно работает, как правило, находит и устраняет ошибки 1 и, таким обазом, у него практически отсутствуют ошибки вида 2.

Пример.

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

С. Относительно смежников.

Могу привести несколько примеров.

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

1. Угол поворота руля.
2. "Газ" (число от 0 до 1).
3. "Тормоз" (число от 0 до 1).

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

Разработчик физической модели не только не предупредил разработчика AI о таком "хаке", но и всячески отнекивался от него.

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

Пример 2. Программа, функционирующая больше года, неожиданно при закрытии стала закрывать кнопочу "Start". Ошибка проявлялась только на одной машине.

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

Искал ошибку совсем другой человек.

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

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

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

С уважением,

• Правила описания ошибки (формуляр) - документирование;
• Описанный набор действий, которые должны быть совершены для проверки конкретного проекта - тестирование.

• Г.С. Альтшуллер  "Уровни изобретений"
• Г.С. Альтов, П.Р. Амнуэль "Шкала оценки фантастических произведений" (Шкала "Фантазия-2)
• И.Л. Викентьев  "Методика оценки методик"

1.1. Составляю список критериев для сравнения

• Критерий-1 (описание)
• Критерий-2 (описание)
• .....................
• Критерий-N (описание)

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

 

1.2. Описываю процедуру сравнения

1.3. Осуществляю сравнение по критериям и делаю выбор

Уважаемые коллеги!

Нашел в сети следующие материалы об управлении программистами и проектами:

1. "Правила Ашманова".
2. "Правила Ашманова". Часть 2: об управлении проектами.

С уважением,

Добрый день!

Уточнения к примеру про модуль шифрования трафика.

На первичное ознакомление с документацией по данному вопросу необходимо около 4 часов. (Документации очень много от нескольких страниц, до многотомников «на всю жизнь».)

1. Произвести сравнение альтернативных модулей – 2 часа

1.1. Составление списка критериев для сравнения – 1 час

            Получились такие критерии:

встроенность в сервер

            документированность

            чистота кода (безошибочность компиляции)

            возможность включения в обе версии сервера

            частота использования

1.2. Описание процедуры сравнения

Не совсем понятен пункт. В этой задаче процедура сравнения – это сопоставление данных

1.3. Осуществление сравнения – 1 час

2. Установка сервера/модуля – 4/1 часа

нового сервера – 4 часа

нового модуля – 1 час

3. Проверка работоспособности сайтов – 2 часа

4. Настройка модуля – 2 часа

4.1. подключение портов - 30 мин.

4.2. создание сертификатов и установка - 1 час

4.3. проверка работы модуля - 30 мин.

5. Перевод сайтов на новый/обновленный сервер – 4 часа

Если пойти по пути установки нового сервера работа занимает – 14 часов

Если устанавливать сразу новый модуль на старый сервер – 11 часов

Если пробовать использовать новый сервер, и если «не пойдет», устанавливать новый модуль на старый сервер – (2+4+2)+(1+2+2+4)=17 часов.

«Проблемными» являются два пункта:

1. Установка сервера/модуля.

Задача в принципе стандартная, выполнялась до этого несколько раз (как установка сервера, так и установка доп. модулей

1. Настройка модуля

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

При выполнении той и другой работы может возникнуть проблема, о которой при ознакомлении с документацией даже не подозревалось.

Решение проблемы может быть как быстрым, так и затяжным. Сколько это потребует времени – сказать невозможно. Иногда «элементарные» вещи отнимают несколько часов. Когда проблема решается – остается только вздохнуть, «как оказывается все просто».

Алгоритм решения таких проблем выглядит приблизительно так (выход на любом шаге):

1. Попытка решить наскоком, перебираются возможные варианты
2. Чтение документации – поиск подробностей, нюансов не замеченных ранее
3. Поиск неофициальной информации (спросить у кого-нибудь, найти в интернете)
4. Локализация проблемы (поиск «оперативной зоны») и ее устранение, либо выбор обходного пути

Вот описал и вроде все просто. За исключением описанной проблемы.

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

Вопросы:

1. Как уточнить время на чтение документации?

2. Как составлять план на месяц, если задач несколько и на каждую нужно читать документацию?

3. Как предусмотреть "непредвиденные" проблемы в плане?