Хаос на работе. Как выжить программисту ?

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

Честно скажу, методика не моя, подсказал один человек, но она реально помогла мне «выжить» и чувствовать себя более  уверенно в тех ситуациях, когда «земля под ногами горит». Может, кто-нибудь возьмет и себе ее на вооружение.

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

1)      В штатном режиме, руководитель принимает задачи на весь отдел, обычные программеры принимают задачи ТОЛЬКО от своего руководителя, либо в крайних случаях, ставят своего руководителя в известность о том, что нужно сделать. В ЛЮБУЮ относительно трудоемкую задачу (более 15 – 20 минут) необходимо ставить руководителя в известность до того, как к ней приступать.

2)      Принимать заявки на разработку, исправление и поиск ошибок ТОЛЬКО  в письменном виде (в нашем случае – это Microsoftoutlook, и документооборот 1С). В письме есть ряд плюсов:

  1. В большинстве случаев, программист – это человек, который реализует желание бухгалтера, менеджера и других специалистов по ведению учета при помощи вычислительных машин.  Но желания этих специалистов могут привести к ошибочным результатам и для кого тогда разведут костер для сожжения ? На слова «А меня Ольга Петровна попросила так сделать» нельзя будет опереться. Вот тут и поможет письмо, которое вы получили ранее с подписью этой самой Ольги Петровны (или его электронный вариант), никто не скажет потом «я этого не просил делать, вы все придумываете»;
  2. Сохраняется четкая формулировка задачи;

3)      Приняв заявку, проводится краткий анализ – возможно ли исполнить заявку быстро или она потребует внимательного и вдумчивого анализа. Если можно сделать сразу, в течение 10 – 15 минут (допустим, настроить учетную запись) – работа делается безотлагательно; если же решение требует длительного времени, мы ставим такую заявку в очередь.

4)     Для каждой выполненной работы создавать пояснительную инструкцию. В условиях большой кадровой текучки — это спасет нервы и сэкономит время на обучении вновь принятых сотрудников. 

Чтобы у инициаторов задач не возникало ощущений, что программисты про них забыли и их задание  ушло «в никуда»,  мы отправляем заказчику ответ письмом в MicrosoftOutlook примерно в таком виде «Надежда Александровна,  необходимые к реализации доработки и замечания описанные Вами, приняты во внимание и находятся  на стадии анализа и разработки. К настоящему моменту в работе подразделения разработки и внедрения, в моей компетенции, находятся следующие заявки в порядке убывания важности и даты поступления (во вложенном файле), если есть необходимость решения каких-либо заданий в более срочном порядке, прошу определить приоритеты  в рамках Ваших задач (позиция текущей заявки в задачах 2).» и прикладываем вложением файл с общим списком задач того специалиста 1С, к которому поступило новое задание (рис.).

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

Скажу по своим впечатлениям и опыту. Возникает какое-то ощущение порядка и спокойствия. Появляется возможность продуктивно и, что самое важное, без спешки качественно работать среди хаоса, нервных срывов и проч. На вопрос «Ну когда же вы мне сделаете..?» можно четко и спокойно обосновать «Номер Вашей задачи 20. И как только у нас дойдут руки – вам все сделают в лучшем виде».

Конечно, случаются исключения из правил – когда нужно сделать именно сейчас и этого требует директор… Тогда приходится до «зеленых соплей», отбросив все сомнения и порядки делать работу.  Но это именно исключение из общего правила. Чем качественнее, вдумчивее и профессиональнее работаешь, тем больше критических ситуаций можно предусмотреть, и как следствие, возникает меньше форс-мажорных ситуаций, к чему нам всем и нужно, думаю, стремиться.

//

51 Comments

  1. Franco

    Ещё — если требуют просят сделать отчёт — просите требуйте пример отчёта в табличном документе (что есть — Excel или Calc, иногда даже удобнее лист бумаги):

    1.Вам легче понять что нужно сделать

    2.Заказчик ‘видит’ (визуализирует) свою мысль:

    2.1 Иногда (и довольно часто) оказывается, что такой отчёт уже есть

    2.2 Заказчик неожиданно осознаёт что оно ему и не требуется

    Бриллиантовая рука, сцена на улице:

    Михаил Иванович: В 9, ровно в 9, гостиница «Атлантика», номер 327, Анна Сергеевна. В 9, ровно в 9. Печёнкой чую, клюнула настоящая рыба. Как она выглядит?

    Горбунков: Она?

    Михаил Иванович: Да.

    Горбунков: Ух!

    Михаил Иванович: Ясно. Будьте осторожны, не повторите вчерашней ошибки.

    Reply ↓
  2. Armando

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

    Это лучше чем аутлук. Все это на одном справочнике и 2 табличные части.

    Reply ↓
  3. karagiosis

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

    Reply ↓
  4. karagiosis

    Баг-трекер на математике 1С…Может он и лучше, чем Microsoft outlook, не буду спорить. Но для нас главный критерий — НАДЕЖНОСТЬ.

    Reply ↓
  5. AllexSoft

    У нас в принципе так же, только для очередей заданий используем ITIL

    Reply ↓
  6. Evgen.Ponomarenko

    У нас колонка «Описание» делится на две части, которые отвечают вопросы «ГДЕ?» и «ЧТО?» соответсвенно. Такое деление добавляет конкретики в постановку задачи,а интегрированная в конфигурацию система help-desk, позволяет формулировать заявки пользователей на права доступа, ошибки и пожелания с привязкой к конкретному документу или отчету.

    Reply ↓
  7. Armando

    На начальном этапе при небольшом количестве пользователей и заявок может и так. У нас сейчас > 150 активных пользователей (он-лайн), большинство косяков устранено. Каждый день имеем штук по 10 новых заявок. И постоянный хвост из 20-25 задач. Год назад хвост был 150 задач. Если бы все это было в аутлуке я бы повесился. И когда в коде что-то меняем, делаем ссылку на номер задачи.

    Reply ↓
  8. karagiosis

    (7) Armando, «И когда в коде что-то меняем, делаем ссылку на номер задачи.»… За идею — спасибо 🙂 возьму на вооружение

    Reply ↓
  9. Armando

    Еще плюс — можно отчеты по задачам формировать. В аутлуке отчет не построишь. Мне в почту каждый вечер приходит отчет по задачам — актуальные задачи, и кто сколько выполнил.

    И еще одну фишку туда запилил — ошибки из журнала регистрации автоматически создаются в баг-трекере и подлежат обязательному выполнению. Такой мониторинг каждый час выполняется. Нужный функционал получился. Много багов так выловили.

    Reply ↓
  10. AllexSoft

    (9) Armando, классная мысль мониторить ошибки в журнале регистрации и отправлять автоматом в баг-трекер! обязательно применю у себя

    Reply ↓
  11. juntatalor

    (9) Armando, это дело. Фоновым заданием журнал регистрации анализируете?

    Reply ↓
  12. Armando

    (11) juntatalor, да. Есть константа, где хранится дата последней проверки. Выборка из журнала от даты последней проверки по текущую дату. После каждой проверки дата обновляется.

    У меня вот так:

    ТекущаяДата = ТекущаяДата();
    
    ТаблицаОшибок = Новый ТаблицаЗначений;
    
    ДатаНачала = Константы.ДатаПоследнейПроверкиЖурналаРегистрации.Получить();
    Если ЗначениеЗаполнено(ДатаНачала) Тогда
    ДатаНачала = ДатаНачала + 1;
    Иначе
    ДатаНачала = НачалоДня(ТекущаяДата);
    КонецЕсли;
    
    Фильтр = Новый Структура;
    Фильтр.Вставить(«ДатаНачала», ДатаНачала);
    Фильтр.Вставить(«ДатаОкончания», ТекущаяДата);
    Фильтр.Вставить(«Уровень», УровеньЖурналаРегистрации.Ошибка);
    
    Колонки = «Дата, Пользователь, ИмяПользователя, ПредставлениеСобытия, Комментарий»;
    
    ВыгрузитьЖурналРегистрации(ТаблицаОшибок, Фильтр, Колонки);
    
    Константы.ДатаПоследнейПроверкиЖурналаРегистрации.Установить(ТекущаяДата);
    
    Если ТаблицаОшибок.Количество() = 0 Тогда
    Возврат;
    КонецЕсли;
    
    // тут обработка таблицы ошибок
    

    Показать

    Reply ↓
  13. DitriX

    у нас вся эта схема в чате реализована 🙂

    Reply ↓
  14. Armando

    (13) DitriX, а кто-то в Twitter постит Twitter клиент на 1С 8.3

    Reply ↓
  15. DitriX

    (14) а смысл? так все находиться в базе, там же задачи помечаются как в выполнении, или как выполненные, там же отчет по времени и т.д.

    Reply ↓
  16. Vladimir Litvinenko

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

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

    Reply ↓
  17. Styvi

    Ещё к этой статье необходимо добавить несколько «готовых ответов» для взаимодействия со «слишком умными» подателями заявок… Вот где нервов-то попорчено!

    Начитаются, что у людей то-то и то-то так-то работает — и начинают заказывать всякие мелочные изменения, утверждая, что это делается за 10 минут (в ущерб реальным потребностям)… А то, что типовые конфигурации ЗУП или БП (баз 5-6 в каждой) мы не хотим менять (и так уже достаточно изменений имеется) ради одной закорючки — не понимают… В итоге — не знаю я — как им без обид объяснить, что печатную форму новую за 5 минут не сделаешь, или регламентное задание типовое не изменишь… А это уже пару часов займёт…

    Reply ↓
  18. karagiosis

    (17) Styvi, думаю, хорошая мысль ) У нас, обычно, с чрезмерно умными пользователями идет общение «вживую»

    Reply ↓
  19. poyson

    Кто нибудь что нибудь новое прочел для себя здесь? Статья на тему «Вау! Я понял как работает сервисдеск!»

    Reply ↓
  20. bulpi

    Был такой анекдот про старого еврея в СССР , ключевая фраза : «наведите элементарный порядок». Статья про это 🙂

    Reply ↓
  21. AllexSoft

    (17) Styvi, встречал особо умных которые начитались и заказывают «вы новый документ скопируйте с такого то типового и вот это перепишите» или «а вот вы этот справочник добавьте нам туда то»… начинаешь объяснять что в вашем случае нужен регистр, так как данные периодические, но нет, им кто то сказал что нужен именно справочник…

    Reply ↓
  22. Gray-SV-02

    не увидел ничего сверхестественного — Именно так и ДОЛЖЕН работать отдел.

    желательно вообще запустить чтонить в рамках ITIL.

    Reply ↓
  23. karagiosis

    Безусловно, рад, что есть высокопрофессиональные специалисты, которые прошли хорошую жизненную школу, для которых грамотно все настроить, обучить людей и учесть все факторы, влияющие на успешную работу в целом — пустяковая задача. Сам факт существования таких специалистов внушает надежду на светлое будущее. Но есть предприятия, которым не настолько повезло с техническим персоналом. Не хватает грамотных специалистов. Катастрофически.

    Reply ↓
  24. karagiosis

    (22) Gray-SV-02, вот именно, что должен. Скоро сказка сказывается, да не скоро дело делается. Можете что-нибудь порекомендовать для изучения и тестирования по тематике ITIL’а ?

    Reply ↓
  25. Abadonna

    (0)

    Вот тут и поможет письмо, которое вы получили ранее с подписью этой самой Ольги Петровны (или его электронный вариант), никто не скажет потом «я этого не просил делать, вы все придумываете»;

    Еще как скажут. Запросто могут сказать, что программист письмо сфабриковал. Просто автор плохо представляет до какой степени подлости могут дойти «Ольги Петровны». Только бумажка с двумя подписями (Ольга Петровна и программист)! В двух экземплярах.

    Reply ↓
  26. karagiosis

    (25) Abadonna, лучше перебдеть, чем недобдеть ? Конечно можно указать, что программист все сфабриковал. Т. е. зашел в систему документооборота под именем бухгалтера, отправил письмо с просьбой изменить схему расчета себестоимости для утверждения на главного бухгалтера, затем зашел под пользователем главного бухгалтера, утвердил, затем перенаправил эту задачу на своего непосредственного руководителя от имени главного бухгалтера…. И сам родил себе головную боль, потому, что он — садомазохист )))

    Reply ↓
  27. Bukaska

    (26) Ну да.. бухгалтера у нас как всегда, ни в чем не повинные люди, а мы как собаки гончие)))) Все палки на нас))) Везде мы крайние)))

    Reply ↓
  28. Abadonna

    (26)

    Могу рассказать как мы на берегу договорились с одной ГБ, с которой всегда душа в душу жили.

    — Юль, пишешь, оба подписываем. Вышло что-то не так, хоть будем знать, кто именно из нас чудак на букву «М».

    Она сейчас финдир компании, в которой ТАКИЕ суммы в долларах крутятся… Но, когда надо что-то действительно нетривиальное, обращается только ко мне.

    Reply ↓
  29. dock

    «1) В штатном режиме, руководитель принимает задачи на весь отдел, обычные программеры принимают задачи ТОЛЬКО от своего руководителя, либо в крайних случаях, ставят своего руководителя в известность о том, что нужно сделать. В ЛЮБУЮ относительно трудоемкую задачу (более 15 – 20 минут) необходимо ставить руководителя в известность до того, как к ней приступать.»

    Если руководитель это допустит (именно в таком изложении) — грош цена руководителю.

    Это задача «Диспетчера по приему заявок».

    Обычно это излагается примерно так: «Все заявки регистрируются в системе регистрации заявок (журнал регистрации).» Само собой руководитель должен просматривать этот журнал — быть в курсе, что происходит. ИМХО «Поставить в известность» = занести в журнал.

    Reply ↓
  30. karagiosis
    Если руководитель это допустит (именно в таком изложении) — грош цена руководителю.

    Это задача «Диспетчера по приему заявок».

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

    Reply ↓
  31. karagiosis

    (28) Abadonna, конечно, когда все отлажено и обе стороны хорошо знают друг друга — можно все построить на доверительном отношении и это отлично. В этом случае и работу делать — настроение лучше и сделаешь качественнее. Тщательное документирование с подписями и прочими заверительными актами подразумевает наличие лжи в человеческих отношениях. Это — дань нынешнему времени когда человек, погибая, с большей долей вероятности увидит не руку помощи, а направленные на него объективы камер смартфонов

    Reply ↓
  32. Armando

    У нас юзеры сами фигачат заявки в систему. Всему отделу приходят уведомления о новой заявке. Проги выбирают себе заявки «по душе», между собой договариваются, кто чем заниматься будет. Я периодически их просматриваю, и если вижу, что заявка несколько часов висит без ответственного, то сам решаю, кто будет ее выполнять. То есть как таковой диспетчер не нужен.

    Reply ↓
  33. karagiosis

    (32) Armando, а если задача поступает такая (кстати, реальный пример), которую никто брать не хочет:

    1) сложная в реализации;

    2) сложная в обучении персонала;

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

    Что делать, когда добровльно не находится героя, чтобы броситься на врага, подобно идальго Дон Кихоту на ветряную мельницу ?

    Reply ↓
  34. Armando

    (33) применительно к нам актуален только первый пункт. Именно из-за сложности заявка может висеть без ответственного. Часто бывает, что задача проста в реализации, но формулировка «страшная», или функционал, в который не любят вникать. Например, изменить алгоритм закрытия месяца по какому-то условию. У нас такие задачи не любят. Тогда я объясняю на пальцах в терминах 1С и объектах системы, и вешаю задачу на кого-нибудь. Иногда и я могу не догнать, чего хочет пользователь. Тогда созваниваемся и добиваемся взаимопонимания.

    Reply ↓
  35. karagiosis

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

    Reply ↓
  36. rasswet

    спасибо, плюсанул, интересно читать статьи, где делятся опытом.

    Reply ↓
  37. karagiosis

    (36) rasswet, благодарю за плюс ) Описывал реальную ситуацию в которую попал сам, что называется, «без прикрас».

    Reply ↓
  38. gala2009

    вспоминаю работу на заводе в отделе ИТ. и 1С 7.7 сопровождали(и дописывали) и галактику. спецы как-то закреплены были за бух.группами, задачи возникали по ходу, и походу решались. неоднократно возникали попытки работать по ТЗ или вести журнал регистрации с подписями бухгалтеров, но потом медленно спускалось на тормозах. прогеров было человек 5-6, сейчас там 1 1С-ник работает, справляется)

    Reply ↓
  39. Mishka_78
  40. Mishka_78

    (2) Вы писали «У нас в каждой ИБ прикручена система типа баг-треккера. Пользователи туда заходят и постят ошибки или задачи на разработку.»

    Интересно было бы посмотреть — не планируете выложить/поделиться? 🙂

    Reply ↓
  41. odin777

    (19) poyson,

    Кто нибудь что нибудь новое прочел для себя здесь? Статья на тему «Вау! Я понял как работает сервисдеск!»

    я прочел, если вас это действительно интересует! Спасибо автору статьи.

    Reply ↓
  42. Andrey@

    У нас на предприятии IT-отдел организовал подачу заявок на исправление ошибок, создание отчетов и обработок через внедренную систему документооборота (не 1С), но обратная связь с приложением очередных задач программиста…это интересно. Менеджеры и бухи порой ругаются между собой, жалуются директору о важности своей проблемы, а потом директор свою полновесную бочку катит на программистов 1с.

    Reply ↓
  43. Aphanas

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

    Reply ↓
  44. Demosagro

    (43) Если лопата мешает Вам копать — повод задуматься — правильно ли Вы ее используете.

    Reply ↓
  45. Aphanas

    (44) А кто Вам сказал, что это лопата будет Ваша и Вы будете ей копать?

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

    Reply ↓
  46. kuzev

    (45) спрашивать должны начальника, а не Вас. Ваша задача копать, а административные вопросы эскалировать.

    Reply ↓
  47. v3rter

    При наличии в IT-отделе более 3 человек кто-то должен быть ответственный за приоритеты. Обычно это начальник, реже зам. А когда надоедает — рождается служебная инструкция по расстановке приоритетов )

    Reply ↓
  48. Aphanas

    (46) Должны? Согласен!

    Толку от этого никакого.

    Reply ↓
  49. necropunk

    Хехе, это разве хаос. Так, слегка повышенная энтропия. Начал расписывать как у нас, перечитал, сам ужаснулся и стер эту лавкрафтовщину. В общем, по делу замечания два: руководителю может быть не до этого, здесь должен быть именно менеджер по заявкам, скрамовцы подскажут как он называется, запамятовал. Он регистрирует, контролирует, пишет все эти письма и, в общем-то, ничего более не делает (при этом по квалификации он должен быть как средний программист). По задачам — на первых порах, пока не добрались до всяких гитов — унифицированный шаблон для всех, где фамилия, начало/конец изменений, дата, номер задачи. Ну, везде свой подход, смотреть надо. Я работал и на крышесносных предприятиях, где ты вообще один и разрабатываешь и совещаешься с руководителями других отделов и пишешь код — вот там времени не было вообще ни на что. Было и такое, что вообще за два года работы с пользователями говорил два раза — все делали менеджеры, все взаимодействия и формализацию, а я просто писал код по ТЗ — вот там производительность была нереальная. Хотя и масштабы доработок тоже. Был и руководителем, но эта вот сортировка задач и взаимодействия с пользователем, чтобы составить ТЗ — точно не задача руководителя. В общем, везде по разному, главное пробовать разные варианты…

    Reply ↓
  50. v3rter

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

    Reply ↓
  51. necropunk

    (50) Да, можно картинку эволюции IT-отделов нарисовать 🙂

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *