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

Крупная разносторонняя ассоциация, множество своеобразных, подчас срочных (нужно было сделать вчера) задач и большая текучесть кадров. В некоторых отделах руководство и персонал сменяются полностью по 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 не будет опубликован. Обязательные поля помечены *