Ускорение работы пользователей 1с
Разработки

Повышение эффективности в четыре руки

Согласитесь, одна голова хорошо, а две лучше! Перефразируем фразу для нашей темы: две руки хорошо, а четыре еще лучше.

  В любом деле существует понятие пробуксовки на какой-либо мелочи. Если один человек что-то не может сделать, то он начинает долго мучиться и искать причину проблемы. И когда ему поделиться своими проблемами не с кем, то поиск решения может занимать очень много времени. В разработке программного обеспечения дело тоже не сможет сдинуться с места, если разработчик (программист) не будет четко понимать, что необходимо сделать, чтоб получилось то, что нужно заказчику. Здесь необходим «тандем» и разработчика, и заказчика. Не будет тандэма – не будет результата. Также если программист не будет иметь возможности проконсультироваться у такого же специалиста как он сам, то есть тандэм разработчик и разработчик, то отдачи от такой работы будет меньше.

Конечно, очень хорошо, когда разработкой занимается целая команда. Внутри команды происходят процессы консультирования и помощи, и работа будет двигаться гораздо быстрее. Но многие малые предприятия не могут себе позволить привлечь команду разработчиков для автоматизации своих бизнес-процессов. А могут привлечь, например, только одного программиста. И очень часто один программист не в состоянии вытянуть весь тот объем работы, который необходимо реализовать в проекте. Один просто не в состоянии охватить абсолютно весь спектр знаний по платформе, по функционалу той системы, которая была взята за основу. Если у Вас есть такой человек, это великолепно. Но это исключительно редкий случай. В данном случае очень полезно применять метод «парной работы». Что это за метод?

 


Метод «парной работы»

Это когда работа осуществляется двумя лицами. Это как в самолете. Есть первый пилот и его напарник — «второй пилот». Но если рассматривать это со стороны пилотов, то они просто друг друга заменяют. В нашем же случае, это все таки два специалиста, которые действуют сообща.

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

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

 

 

Польза

 
В парной работе есть свои плюсы. В разных технологических фирмах (например, Facebook, Square) почувствовали пользу совместной работы. Они утверждают, что программисты лучше выявляют дорогостоящие ошибки программирования. И кроме того, сотрудники тратят меньше времени на свободный поиск на просторах интернета информации, не связанной никоим образом с работой, другими словами на ерунду. Общение в такой работе между двумя выходят на иной уровень, более глубокий, профессиональный. Иной раз даже слова не используются. И здесь всецело проявляется поговорка «одна голова хорошо, а две лучше». У обоих круг знаний гораздо шире, чем у одного. Один умеет хорошо искать и аккумулировать идеи, а другой их реализовывать и воплощать.

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

 Ну вот, например, главный бухгалтер и программист. У первого знания в области бухгалтерского учета, у второго знания инструмента автоматизации. Если главный бухгалтер будет ставить задачи и в последующем отстраняется от процесса, когда программист будет реализовывать это в конфигурации, то может получиться так, что программист поймет так, как понял, и будет реализовывать по-своему видению. И в конечном итоге может результат работы зайти совсем в другую сторону. При этом, если еще и задача была поставлена расплывчато, то результата вообще можно не дождаться. Когда же работа происходит «в живую» вдвоем — процесс явно пойдет быстрее. Сработает эффект присутствия. И время будет сэкономлено разработчика и заказчик сэкономит свои финансы. Конечно, здесь можете возразить, что какая может быть здесь экономия, если задействован более дорогостоящий сотрудник – главный бухгалтер в данном процессе. В целом это ведь всего-лишь пример. И еще вопрос кто из этих специалистов будет дорогостоящим. На рынке труда разных вариаций достаточно много. Речь идет о том, что именно главному бухгалтеру как заказчику нужно то, что будет делать разработчик. А следовательно, как следствие, он в будущем сэкономит либо свое время, время своих сотрудников, либо средства своей компании, при автоматизации бизнес-процессов. Да и не обязательно это должен быть главный бухгалтер. Здесь достаточно задействовать ключевого сотрудника, который в данной области имеет достаточные знания.

 

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

 


Идея


 

Сегодня идею парной работы берут на вооружение многие компании-разработчики и называют это «парное программирование». Причем одни работают постоянно с одним и тем же партнером, другие меняют партнеров ежедневно, называя эту практику «случайным партнерством». Есть также другие виды партнерства, например партнерство в стиле «пинг-понг», когда партнеры взаимодействуют так, будто перекидывают друг другу мяч, как в пинг-понге, то есть меняются местами. Еще один вариант – парное программирование на удаленном доступе, когда программисты делят один экран через интернет. Можно работать в паре на постоянной основе. Кто-то предпочитает объединяться в пары время от времени.
 

 На опыте довольно часто приходилось применять метод парной работы, когда приходилось внедрять учетную систему на тот или иной участок. Выявлялся в процессе ключевой сотрудник и вместе с ним происходила работа до самого окончания процесса внедрения разработки. Что из этого выигрывала та и другая сторона? Обе стороны даже с учетом многолетних своих приобретенных навыков и опыта совершенно не представляют что нужно друг другу. Довольно часто заказчик не может сформулировать, что ему в конечном счете нужно и каким способом это возможно решить. И тем более сформулировать это в письменном виде. Разработчику порой бывает также трудно предположить каким способом это реализовывать. Конечно, хорошо когда разработчик опытный и действительно у него за плечами богатый багаж знаний, и, самое главное, уже готовые инструменты, которыми он может воспользоваться в процессе разработки. Но сколько бы не имел знаний разработчик практически всегда получалось делать то, чего не оказывается в этом «багаже». К тому же время не стоит на месте. Развивается сама платформа 1с, появляются новые инструменты, новые прикладные решения. Все это нужно изучать и учиться новому, развивать свои умения. К тому же, еще ни одному предприятию на нашем опыте в 100%-м виде пригождались уже так сказать готовые разработки. Все приходилось дорабатывать, а иной раз и полностью перерабатывать под новые бизнес-процессы.
 
В идеале парная работа должна приносить гораздо больший результат, чем справляться с работой в одиночку. И если такое возможно, то лучше этот метод применять. Главное чтобы в этой паре присутствовало взаимопонимание и они были единомышленниками.

 



Вывод

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

 


Нравится 0 Не нравится
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо зайти на сайт под своим именем.
Добавить комментарий
Ваше имя: *
Ваш e-mail: *
Вопрос: Юзабилити - это удобство работы в программе?
Ответ:
Код: Кликните на изображение чтобы обновить код, если он неразборчив
Введите код: