На сайте ведутся работы Создание системы заработной платы для программистов | Нематериальное стимулирование, компенсационные пакеты | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » Нематериальное стимулирование, компенсационные пакеты » Что мешает программистам IT-отделов…

Создание системы заработной платы для программистов

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2003-10-20 10:00:06
Александр Шатов » Всем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Показать все ответы на это сообщение]
2003-10-22 18:41:17
Сергей В. Сычев » Александр Шатов
Уважаемый Коллега!
 
А. Относительно ошибок:
 
1. Часы, потраченные программистом на исправление ошибок им же допущенных, нельзя учитывать, как результативные. То есть, это НЕ дополнительная работа, которая должна оплачиваться.
 
2. Для "стока" противоречивых ситуаций (например, когда программист приводит аргументы, которые трудно проверить и/или ссылку на внешние обстоятельства или среду и/или иное) рекомендуется описать, как ошибку, так и ее "уважительную причину" в спец. журнале. Мы его называем "журнал рассогласований".
 
Если ошибка описана в таком журнале, то ситуация может трактоваться в пользу программиста.
 
Далее каждый месяц проводится мониторинг "Журнала рассогласований". Обычно, после определенного количества записей - все или многое становится понятно.
 
3. Разумеется должен быть стандарт на тестирование и стандарт на документирование ошибок.
 
В. Относительно инициативы:
Уточните. Говоря об инициативе, Вы имеете в виду переработки (они, как нам кажется, учтены в модели которую Вы описали). Цитируем: "А если выполняет план, то либо выполняет другую задачу (и по итогам месяца получает больше)...".
 
Или Вы имеете в виду необходимость "премии за креативность" (за качество решения) - так скажем?
 
С. Относительно смежников:
Можете ли Вы привести 3-4 характерных конкретных примера, когда (в Вашем случае!) один сотрудник подводит другого.
 
Примечание. Мы ни в коей мере, не сомневаемся в том, что это вероятное и даже частое явление. Мы просто хотели бы попробовать дать ответ с учетом вашей специфики.
 
Д. Относительно норм времени:
Профессия может быть сколь угодно творческой, а каждый проект, тем не менее, конкретен.
 
Если задача сложна (трудно измерить ее продолжительность), рекомендуется поручить сотруднику описать все этапы решения задачи (последовательность работ) с заданным шагом, например, в 2 часа (в ряде случаев, шаг может быть более дробным, в ряде случаев - менее).
 
Крайне редко (даже на действительно сложных проектах) бывает так, что каждый из таких шагов трудно выделить. А если сотрудник утверждает обратное - есть повод задуматься над его квалификацией.
 
Тем не менее, в контексте проекта, вполне могут оказаться НЕКОТОРЫЕ ДРОБНЫЕ (см. выше) этапы (А НЕ ВСЕ!), продолжительность которых на этапе постановки задачи неочевидна.
 
Таковые надо выделить и показать заранее (продекларировать) руководителю и дать соответствующие рабочие пояснения. После чего такие ЛОКАЛЬНЫЕ этапы следует раздробить еще сильнее, то есть попробовать описать с еще меньшим шагом (1 час, 30 минут...).
 
Задача, как бы, обостряется. Выделяется "оперативная зона проблемы". Повышается прозрачность.
 
По таким позициям возможен согласованный временной "допуск" на продолжительность.
 
Разумеется время затраченное на подготовку такого плана считается продуктивным и оплачивается.
 
Все это можно разобрать и на конкретном Вашем примере, если Вы его приведете.
 
Большое спасибо,
[Показать все ответы на это сообщение]
2003-10-27 14:25:01
Александр Шатов » Сергей В. Сычев

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

А. Про ошибки

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. научить каждого пользоваться.

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

[Показать все ответы на это сообщение]
2003-10-30 11:59:26
Кирилл Лебедев » Всем

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

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

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

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

  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. Один программист разрабатывает инструмент - "умные указатели". Он утверждает, что эти "умные указатели" самые хорошие, т.к. позволяют избежать типовых ошибок при работе с указателями. И эти "умные указатели" должны заменить другие, которые использовались в фирме ранее.

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

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

С уважением,

[Нет ответов на это сообщение]
2003-11-01 17:22:58
Сергей В. Сычев » Александр Шатов
Уважаемый Александр! Вы пишете:
 
"2. Если я правильно понял, в "Журнал рассогласований" заносятся те ошибки, про которые нельзя однозначно сказать, что они допущены по вине работника.
Вопрос. Не совсем понятно, что дальше? Далее, если ошибка повторяется и она описана в журнале, то ситуация уже трактуется не в пользу программиста? Т. е., другими словами, составляется журнал типовых ошибок, возможность появления которых нужно учитывать при разработке ПО? Что-то не так в моих рассуждениях или совсем не так?"
 
Ответ: Относительно одной и той же ошибки не может быть двух или более записей в журнале, которые трактуются в пользу программиста.
 
Если это записи об одной и той же ошибке и указана одна и та же причина ее появления, то значит причина ошибки не была устранена должным образом.
 
Если это записи об одной и той же ошибке и указаны разные причины ее появления, то значит ситуация либо пока еще не понята программистом, либо сделаны "отписки".
 
Увеличение числа разных причин одной и той же ошибки - основание для внешнего аудита.
 
Большое разнообразие записей (большое число разных ошибок и разных причин) в одном проекте (или тем более в одной подсистеме) говорит о качестве работы В ЦЕЛОМ.
 
"3. Что представляет собой стандарт? Это определенный алгоритм и/или набор правил, по которым происходит тестирование/документирование. Есть ли правила его создания?"
 
Ответ:
  • Правила описания ошибки (формуляр) - документирование;
  • Описанный набор действий, которые должны быть совершены для проверки конкретного проекта - тестирование.
В случае появления ошибки после тестирования (после сдачи проекта), рекомендуется не только устранить ее, но и дополнительно применить, т.н., "диверсионный анализ" Б.Л. Злотина. А именно ответить на вопрос: "Какими способами еще (не изменяя систему) можно вызвать данную ошибку?"
 
"Здесь видно два уровня "креативного подхода". Первый - это "просто системное понимание" (проблема его привить), второй - действительно креативное решение, учитывающее разные нюансы. И тот, и тот подход нужно как-то поощрять".
 
Ответ:
 
Если Вы можете формализовать эти "качественные уровни" (не факт, что их всего два), то сможете формализовать и модель заработной платы.
 
См. аналоги:
Приведем пример из редакционной деятельности данного сайта.
 
Три опытных журналиста побывали на выставке и написали на этот сайт по одной статье равного объема.
 
Но один из них написал просто информационную статью о том, что он увидел, перечислил участников, организаторов, спонсоров и т.д. (Уровень 1).
 
Второй - описал несколько удачных приемов привлечения Клиентов, проанализировал почему при одинаковых товарах у одних стендов много людей, а у других - мало. (Уровнь 2).
 
Третий же написал пошаговую методику привлечения Клиентов к стенду и проиллюстрировал ее примерами. (Уровень 3).
 
Вопрос: "Как Редакция сайта "Рекламное Измерение" заплатит каждому? При том, что объем работ одинаков и все 3 работы приняты".
 
Объем измеряется в страницах формата А4. А способ определения уровня нами формализован. Мы умножим объем на "уровень" и получим оценку в баллах. При этом, согласно нашим правилам, третий получит по 3 балла за полосу, а первый - по 1.
 
Ключевой момент. Каждый "творческий сотрудник" у нас должен быть не просто "творческим", а набирать определенное число баллов в месяц. (Более того, ему заранее выдаются конкретные соответствующие задания).  Если набирает, то получает высокую зарплату. Иначе - увы.
 
Сама по себе работа по формализации уровней довольно тяжелая. Можно сказать, что это работа 5-го уровня. Тем более, что помогать никто не захочет (в том числе, те, кому Вы хотите за творчество увеличить зарплату), а объяснять почему не получится и почему "не подходит" будут многие. Но, если в Вашей деятельности это необходимо, то надо делать.
 
Что касается нас, то работа над формализацией качественных уровней работы программиста, нами сейчас ведется. И, вероятно, через некоторое время мы сможем кое-чем поделиться.
 
О смежниках и о нормах времени - чуть позже в следующих сообщениях.
 
С Уважением,
[Нет ответов на это сообщение]
2003-11-02 14:42:58
Сергей В. Сычев » Александр Шатов
Уважаемый Александр! В данном сообщении информация относительно смежников.
 
Фрагмент-1:
 
"1. Дизайнер заболел. Верстальщик/программист не может создавать страницы сайта не имея общей концепции. Выполнять следующую работу он не может, поскольку еще отсутствует техническое задание на эту работу".
 
Предположительная причина: малое число заказов.
 
Рекомендации:
 
а. Проверить модель заработной платы менеджеров отвечающих за продажи;
б. Заполнить простои верстальщика/программиста работой по созданию стандартов на верстку, а также работой по созданию шаблонов страниц.
 
Судя по ранее описанному (цитата ниже) в фирме таковые отсутствуют:
 
"1. После создания новых разделов на веб-странице, оказалось, что в разных частях страницы отступы между строчками разные. Теоретически работа выполнена. Фактически - требуется небольшая доработка, которая замечается через некоторое время на этапе тестирования.
2. Добавляется новая страница сайта. Она должна быть оформлена в том же стиле, что все остальные. Можно донимать дизайнера по поводу каждой "закорючки", а можно самому все сделать красиво".
 
Фрагмент-2:

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

"4. Из-за срочной работы (появившейся внепланово) один из сотрудников задерживает выполнение своего этапа работы, а следовательно задерживает всех остальных".
 
Если такие срочные внеплановые работы происходят часто, то предположительная причина: слабый менеджмент, если редко, то - пожалуй - нет задачи. Судя по тому, что остальным нечем заняться - малое число заказов.
 
Рекомендации:
 
Всю внеплановую работу разделять на следующие три группы:
 
а. Аварии и ошибки;
b. Внезапность, вызванная Клиентом, но не связанная с аварией и/или ошибкой;
c. Все остальное (не попадающее в первые 2 группы).
Все, что попадает в группу "с" делать только в понедельник (или в иной специально выделенный день). Пояснение: лучше все "раздергивание" локализовать во времени.
 
Все, что попадает в "а" и "b" документировать в отдельных журналах, которые анализировать еженедельно (менеджеру). Ключевой вопрос тот же, что и ранее: "Насколько часты события по п.п. "а" и "b"?
 
О нормах времени - в следующих сообщениях.
 
С Уважением,
[Нет ответов на это сообщение]
2003-11-02 17:35:37
Сергей В. Сычев » Александр Шатов
Первый разбор примера про модуль шифрования трафика.
 
Уважаемый Александр!
Вам следует позицию "прочитать документацию" вынести из общего плана. То есть, надо указать сколько времени Вам потребуется на первичное ознакомление с документацией. План же составить уже после этого.
 
Нам представляется, что после ознакомления с документацией возможна следующая раскладка.
 
1. Произвести сравнение альтернативных модулей
1.1. Составляю список критериев для сравнения
  • Критерий-1 (описание)
  • Критерий-2 (описание)
  • .....................
  • Критерий-N (описание)
При этом, заметим, что "уже встроенность" одного из альтернативных модулей в сервер - это, возможно, лишь один из критериев.
 
1.2. Описываю процедуру сравнения
1.3. Осуществляю сравнение по критериям и делаю выбор
2. Устанавливаю сервер/модуль
3. Проверяю работоспособность сайтов
4. Настраиваю сервер/модуль для использования существующих портов
5. Создаю сертификаты безопасности
6. Устанавливаю сертификаты безопасности
7. Проверяю сертификаты безопасности
8. Перевожу сайты на новый сервер
---
Пожалуйста,

I. Поправьте/уточните приведенный выше алгоритм, если это необходимо.
II. Укажите время, необходимое для реализации каждого пункта (1-8). При этом, руководствуйтесь предположением, что предыдущие пункты выполнены нормально.
III. Вынесите в отдельное рассмотрение только те пункты, по которым Вы затрудняетесь это сделать. (Не может быть, чтобы по всем).
 
Сделайте эту работу (I-II-III), затем продолжим, как с этим, так и со следующим Вашим примером.
 
С Уважением,
[Показать все ответы на это сообщение]
2003-11-05 18:30:52
Кирилл Лебедев » Всем

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

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

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

С уважением,

[Нет ответов на это сообщение]
2003-11-15 14:16:05
Александр Шатов » Сергей В. Сычев

Добрый день!

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

На первичное ознакомление с документацией по данному вопросу необходимо около 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. Как предусмотреть "непредвиденные" проблемы в плане?

[Показать все ответы на это сообщение]
2003-11-19 14:14:07
Сергей В. Сычев » Александр Шатов
Уважаемый Александр! Большое спасибо за проделанную работу!
 
Прежде, чем ответить на вопросы, несколько важных, на наш взгляд, как бы "вводных", мыслей.
 
Мысль - 1. Работа, которую Вы сейчас делаете и которая продемонстрирована Вами в приведенном примере - это и есть нормальная работа менеджера (подходить к сотруднику, нормировать его работу и формализовывать сложные задачи и т.д.). Это бывает трудно, но это работа. Хороший менеджер ее никогда не избегает, а проводит регулярно и - более того - накапливает задачи по мере их поступления в журналы (картотеки).
 
Мысль - 2. Такая работа должна проводится не только с программистами, а она полезна для управления любыми сотрудниками, занятым в сложной предметной области.
 
Перейдем к примеру.
 
Был вопрос о процедуре сравнения.
Вы выбрали критерии для сравнения альтернативных модулей.
 
- встроенность в сервер
- документированность
- чистота кода (безошибочность компиляции)
- возможность включения в обе версии сервера
- частота использования (под частотой использования" Вы понимаете "распространенность" или иное? - Ред.)
 
Возможный алгоритм сравнения: каждому из выбранных критериев присваивается "вес", если значимость их разная (например от 1 до 2, возможны промежуточные значения - десятичные дроби). Если значимость одинаковая, вес каждого = 1. Просто смотрите сколько баллов набрал каждый модуль.
 
Важно! Если этот алгоритм кажется неточным, то, возможно, пропустили какой-то критерий (то есть, решения принимаются не только на основании перечисленного).
 
Перейдем к плану.
 
Вероятно, Вы не указали еще 6-й пункт плана, который мог бы звучать так:
 
6. Проверка работоспособности сайтов после перевода их на обновленный сервер.
 
Причем у Вас должен быть формализованный алгоритм такой проверки (уверены в том, что он есть). Мы также уверены в том, что Вы не делаете перевод всех Клиентов на обновленный сервер сразу "вживую", а сначала делаете это на тестовой машине полностью аналогичной (и по железу и по софту) рабочему серверу.
 
Теперь обсудим "непредвиденные проблемы". Как было сказано выше, они должны быть продекларированы внесением в журнал (с указанием на какой позиции плана находится соответствующая проблема).
 
Рассмотрим на Вашем примере. Пользуемся этими данными (цит.).: "оказалось, что не работает система авторизации на одном из сайтов". Понимаем, что это произошло на п.6. плана.
 
В этот момент программист либо вносит задачу в журнал, либо его аргументация о полезном перерасходе времени не будет принята во внимание. То есть, если задача несложная и ему быстрее исправить ошибку (решить задачу), чем ее формализовывать, то и вопроса нет для обсуждения. Если же он "залип", то ему лучше спокойно и по формуляру записать задачу в журнал и потом решать ее.
 
Рекомендуется, чтобы заданный в журнале формуляр предполагал и описание способа решения задачи (до или после решения). То есть, человек может спокойно подумать и спокойно описать/прорешать задачу. Время на описание задачи и ее решение в этом случае считается продуктивным.
 
Относительно приведенного примера можем предположить следущее. По контексту ваших сообщений предполагаем что сайт у которого не сработала система авторизации стоит не на отдельном сервере, где нет других сайтов кроме него, а стоит на сервере, где есть и другие сайты. Причем у остальных система авторизации нормально функционирует.
 
Если это верно, то рациональный алгоритм действий программиста/админа (и соответственно запись в журнале) мог бы выглядеть так:
 
1. Исправляю конфигурационный файл. (Этого может оказаться достаточно).
 
Если после исправления конфигурационного файла ситуация не изменилась, то пишем так:
 
1.1. Нахожу в конфигурационном файле зону ответственную за сайт N (не работает авторизация)
1.2. Нахожу в конфигурационном файле зону ответственную за сайт M (работает авторизация)
1.3. Нахожу отличия между M и N
1.4. Описываю отличия
1.5. Вношу изменения
 
Если после п.1.5. ситуация не изменилась (либо отличий не обнаружено) понимаю, что есть новое правило "ИКС" на уровне нового сервера (которого нет в старом сервере). Поэтому отправляю запрос в службу поддержки, размещаю задачу на таких-то Форумах и т.д., а пока откатываюсь на старую версию. И т.д..
 
На перечисленные работы по п.п. 1 - 1.5. у меня ушло __ (указать). Подпись".
 
Далее дело менеджера принять решение: настаивать на новой версии сервера (соответственно, выделять время на активное решение задачи), либо работать на старой и ждать пока придет ответ из службы поддержки или из иных пассивных источников.
 
Возможны и иные более удобные для Вас формы записи. Важна суть.
 
А суть заключается в том, что такие формулировки, как
 
"пытался переработать систему авторизации на неработающем сайте. Этого сделать не удалось в силу серьезных изменений в новой версии сервера (необходимо еще неизвестно сколько времени изучать документацию)"
 
или
 
"несколько раз приходилось повторять процедуру добавления модуля и чтения документации, поскольку каждый раз появлялся какой-нибудь нюанс" - неверны, ибо они носят слишком общий характер и никак не проясняют ни характер работы, ни характер возникшей задачи.
 
Наоборот, формулировки такие, как 1-1.5. конкретны и проясняют, как характер работы, так и характер возникшей задачи.
 
Массив же таких конкретных записей проясняет (по мере накопления), как квалификацию специалиста, так и состояние проекта. А кроме того позволяет делать так, чтобы задача однажды уже решенная больше не повторялась.
 
В итоге через определенное время количество "непредвиденных ситуаций" просто резко уменьшится.
 
Вопрос: "Как уточнить время на чтение документации? и Как составлять план на месяц, если задач несколько и на каждую нужно читать документацию?"
 
Ответ: И здесь истина конкретна. Мы не думаем, что каждый месяц нужно читать многочисленную новую и разнообразную документацию.
 
Мы думаем, что речь, скорее всего, о следующем:
 
а) операционка (например, соотв. UNIX или Win)
б) web-сервер (например, Апач или IIS)
в) база данных (которую Вы используете)
г) документация по языкам, которые Вы используете (perl, php, asp или иные)
д) ................
 
Уточните или продолжите этот список.

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

С Уважением,
[Нет ответов на это сообщение]
2023-05-10 13:39:38
Артем » Александр Шатов
https://rrdecor.ru/
[Нет ответов на это сообщение]
2023-08-15 17:31:39
Артем » Александр Шатов
Проект LEAF существует на рынке с 2012 года. За долгое время работы мы смогли вобрать огромное количество опыта, знаний и обратной связи от различных спецподразделений и военнослужащих в тех или иных сферах нашей деятельности.
Благодаря широкой материальной базе и специалистам, трудящимся в Проекте над созданием предметов тактической медицины, бронезащиты и снаряжения, мы имеем возможность предоставлять высококачественный продукт, отвечающий всем современным вызовам на поле боя.
[Нет ответов на это сообщение]


Яндекс.Метрика