gifts2017

Рекомендации по организации отдела разработки (идеальная программа 2)

Опубликовал Виталий Трач (vitalya24) в раздел Управление - Управление проектом

Краткий список рекомендаций при организации отдела разработки или фирмы по созданию программных продуктов. Из личных наблюдений и опыта.


1. Еженедельный семинар отдела разработки.

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

Руководитель собрания проводит брейншторм по каждой задаче с группой, работа над каждой задачей не более 5 -10 минут, затем человек, владелец задачи, записывает такие идеи(мысли) и в последующем анализирует уже самостоятельно и принимает решение. Такой краткий семинар проводить в непринужденной обстановке но тем не менее в офисе. 

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

 

 

2. Групповое размещение команды.

Команда программистов согласно методологии гибкой разработки (SCRUM) должна находиться вместе. Результат: обмен опытом, быстрое решение проблемных длительных задач, взаимозаменяемость сотрудников, сплоченность команды при больших проектах. 

 

3. Доступ к серверам 1с и серверам баз данных. 

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

Результат: Сокращение времени при возникновении проблем именно с бд на уровне sql и кластеров серверов 1с8, ликвидация проблем  задержки во времени, как следствие ускорение общего процесса решения технических задач и проектов. 

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

 

 

4. Обучение базовым навыкам конфигурирования специалистов технической поддержки.

 Так как служба тех поддержки так же выполняет роль тестирования продуктов (результатов) разработки, реализовать обучение специалистов службы поддержки конфигурированию в системе 1с8, структуре объектов, базовым принципам и навыкам программирования, разрешить доступ к конфигурациям, только для просмотра.  

 

5. Парное программирование.

Возможно рассмотреть вариант парного программирования опять таки из методологии SCRAM.

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

 

6. Оптимизация производительности.

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

Так же проводить опрос пользователей на предмет выявления узких мест в существующих системах учета и регулярно проводить оптимизацию, выявляя проблемный код например при помощи 1С Центр Управления Производительностью.

Результат: предупреждение проблем производительности и как следствие ускорение работы пользователей, исключение возможных простоев.

 

7. Политика открытого управления для сотрудников отдела разработки систем учета.

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

 

8. Объединение всех узлов ИТ-структуры компании единой шиной.

Организовать обмен данными между узлами (базами, системами учета, и т.д.) структуры при помощи единого интерфейса взаимодействия с использованием например IBM WebSphere Message Broker из линейки продуктов IBM WebSphere MQ.

9. Ввести Систему управления человеческими ресурсами

  1. Карточка каждого сотрудника.
  2. Динамика развития.
  3. График тренингов и развития сотрудника. Не развивающиеся сотрудники не нужны компании.

Профессиональная направленность сотрудника. Приоритетные направления.

  1. Периодические тестирования и повышения квалификации сотрудников.
  2. Загрузка команды и отдельного сотрудника.

 

10.Ввести систему для учета задач

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

 

11.Профилирование сотрудников, проектных команд.

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

 

12.Разработка через тестирование.

  1. Донести до разработчиков методику разработки TDD, разработка через тестирование. (как должно работать - разработка - Рефакторинг)

 

13.Введение локальной wiki компании.

  1. Обмен информацией.
  2. Инструкции, корпоративные документы, особенности работы систем, специфика работы узлов (1с, не 1с), модулей.
  3. Упростит обмен информацией между существующими сотрудниками и значительно ускорит скорость входа полноценный рабочий режим работы новых сотрудников, не затрачивается время опытных сотрудников на обучение новых.
  4. Простое добавление новой информации, простой поиск.
  5. Снижение рисков внезапного ухода ценного сотрудника, при условии документирования реализуемых проектов и задач.
  6. Возможно,  создать корпоративную wiki которая будет доступна с корпоративного сайт
14. Обучение специалистов службы поддержки базовым навыкам программирования, сертификация специалистов
 

 

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Eugeneer (Eugeneer) 04.08.13 12:04
2. Виталий Трач (vitalya24) 04.08.13 12:08
(1) Eugeneer, ну этот бред скорее всего для начальника отдела разработки, чем для инженера, программистам может и не понравиться
3. Роман Романов (romansun) 04.08.13 12:56
да не, всё так...

можете рассказать, что используете/пробовали в качестве:
- систему управления ресурсами
- системы учета задач
- wiki
- чуть подробнее про TDD: как, что, по чем, примеры :)
Taktic; help1Ckr; +2 Ответить 1
4. Дмитрий Литовченко (kompas-dm) 04.08.13 13:15
(0) Где-то 70 годы. Так и было.
5. Виталий Трач (vitalya24) 04.08.13 13:38
(3) romansun,

- систему управления ресурсами:

Фактически это работа отдела управления персоналом (работа по управлению ресурсами).
Софта готового не нашли дорабатывали сами.

- системы учета задач

Пробовали много всего. Можно расположить в хронологическом порядке:
1. Эксель (еженедельная таблица, что сделал за неделю, что буду делать на следующей неделе)
2. Подсистема в рабочей конфигурации по учету задач
3. TeamLab http://www.teamlab.com
4. TrackStudio, http://www.trackstudio.ru free-система учета задач
5. RedMine http://www.redmine.org
6. Trello https://trello.com/ - канбан доски он лайн
7. Собственная разработка управления задач на управляемом интерфейсе с учетом скрам методологии.


- wiki

была сначала какая-то вики что-то фришное на линукс какой-то пакет (если интересно можно напрячься и вспомнить).
Собственно сейчас все есть в RedMine

- чуть подробнее про TDD: как, что, по чем, примеры :)
По определению:
Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам.

По факту применимо при больших проектах когда одна группа разработки не знает что делает другая...
В более мелких тз более применимо разработка в две руки если это позволяет человеческий ресурс.
6. Ирина Павленко (PAVI) 04.08.13 13:43
Тоже из опыта:
1. Еженедельный семинар проводился в офисе фирмы-франчайзи (так удобнее начальству), вечером (чтобы сэкономить рабочее время). А я к вечеру уже никакая...
2. Групповое размещение в фирме-Заказчик было столь плотным, что когда один член команды хотел пи-пи, вставать должны были человек 5.
3. Прямой доступ к 1С и серверам?! Честное слово, если вы сторонний разработчик, то от этого лучше открещиваться, иначе вас будут обвинять во всех смертных грехах.
4. Обучение базовым навыкам конфигурации специалистов техподдержки...И это бывало, но достает, когда одно и то же в 20-й раз. Хорошо еще, если с новым человеком. А когда этот спец имеет другое мнение о своих должностных обязанностях и на мнение начальства и твои старания ему...
Taktic; fuxic; zse; vitalya24; +4 1 Ответить 1
7. Виталий Трач (vitalya24) 04.08.13 13:48
(6) PAVI, все зависит от организации, реализации, можно и суп так сварить что технически это будет суп, а есть его нельзя будет:)
8. Роман Романов (romansun) 04.08.13 15:36
(5)
Меня вот во всей этой теме интересует больше всего тестирование таки. К примеру, как вы оцениваете трудоёмкость при TDD, ведь, по идее, она должна возрастать в разы... Как сами разработчики относятся к TDD и ко всем сопутствующим сложностям? Пишите какие-либо приспособы для прогонки тестов?

Не хотите отдельную статью тиснуть при наличии времени/желания? ;) Тема очень интересная и в 1С практически отсутствующая вообще.

По поводу остального - да, со всем согласен. Мы используем JIRA и, соответственно, Confluence. Trello еще тоже местами. Ну и всякого разного по мелочи...
9. ivanov660 ivanov660 (ivanov660) 04.08.13 15:44
Хорошая подборка директив - особенно подходит для внутренних отделов больших компаний. Однако, в отечественных реалиях некоторые пункты не выполнимы из-за современного менталитета, к сожалению. Это касается "базы знаний", рефакторинга кода и других пунктов в большей или меньшей степени.
10. Виталий Трач (vitalya24) 04.08.13 16:54
(8) romansun, как-то много времени уделил этому вопросу. Среди прочих программ были Сценарное тестирование из КИП, и разработки ИБМ для создания сценариев тестирования. Попробую уделить время и изложить мысли...
11. Eugeneer (Eugeneer) 04.08.13 22:20
Вообще не уделено конкретным целям. И как организовать компанию, у которой есть реальная концепция развития.
Все что сказано простые истины построения бизнеса. Какие то собрания и прочее - ну муть же. Как будто этого нет.
Чтобы делать дело нужны другие подходы.
d.zhukov; CratosX; h00k; vitalya24; +4 Ответить 2
12. Виталий Трач (vitalya24) 05.08.13 10:41
(11) Eugeneer, странно, а что вам не понятно? это всего лишь рекомендации на основе личных наблюдений, большинство из которых успешно внедрено. Если недостаточно инструментария то я могу описать.
13. Виталий Трач (vitalya24) 05.08.13 10:56
(11) Eugeneer, кстати, некоторое время изучал такое направление как разработка ИТ-стратегии бизнеса, и пришел в выводу что очченнь немногие компании занимаются написанием такого документа, хотя имеют большой штат ит-специалистов. Я согласен что реалии жизни немного отличны от "сферического коня в вакууме", но например первое из предложенного списка, заимствованное из метологии скрам, нам помогло...
14. Виталий Трач (vitalya24) 05.08.13 10:58
(9) ivanov660, как ни странно база знаний у нас есть, штат отдела праммного направления примерно 40 чел...
15. Денис Бурлыко (borodabmc) 06.08.13 12:48
По статье - практически все, что описано есть у нас! Спасибо, за то, что обратили внимание на данную тему!

Наличие налаженного процесса выпуска программного продукта характеризует зрелость IT-компании. Фирма, в которой я работаю, в свое время начинала с "хаоса". Но росли объемы, увеличивался штат, появилась специализация в работе (разработка, тестирование, внедрение). Адаптировали для себя Agile-методологии SCRUM и KANBAN. SCRUM на проектах , KANBAN в оперативной работе и поддержке. Допиливал управление задачами в нашей внутренней системе для учета особенностей методологий, потом внедрял в работу. Себя оправдывает.


Разработали внутренний стандарт разработки на основе методологий фирмы 1С. Проводим code review. Готовим молодых спецов, проводим семинары по наболевшим темам, обмениваемся опытом...
amon_ra; help1Ckr; vitalya24; +3 Ответить 1
16. Виталий Трач (vitalya24) 06.08.13 12:56
(15) borodabmc, много плюсов за ответ:)))
17. Вячеслав Клюев (slavik27) 07.08.13 09:36
Спасибо статья хорошая, было бы интересно знать как вырасти из небольшой компании (1-2 чел) в компанию, которая имеет команду специалистов
18. Виталий Трач (vitalya24) 07.08.13 10:26
(17) slavik27, сам такого опыта не имею. Ранее работал в одной компании в "группе" разработчиков из 2х человек:) потом ушел в другую компанию, а второй разработчик создал франч, набрал людей и работают...
19. Андрей (h00k) 07.08.13 10:54
Мда, заголовок интригующий, но содержание... сборник цитат из методик "eXtreme Programming" опубликованной в начале 2000х и позднее развившейся в несколько разных направлений.

Но за статью в любом случае плюс. В связи с тотальным не умением пользоваться поиском для многих данная информация может оказаться откровением.
20. Alex Stasyuk (GreenFox) 07.08.13 12:05
Вснесу свои 5 копеек.

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

График повышения квалификации и карточка сотрудника тоже должна быть, как и четкая система мотивации, к примеру сдал спеца - оклад повысили, сдал профа - премия.

Доступ к серверам - не уверен. Тут раньше писали, что все проблемы будут валить на разработчиков - это факт. Но учебный SQL-сервер для экспериментов в самой фирме-франчайзи быть должен. Люди должны развиваться и изучение клиент-серверной архитектуры и взаимодействия с SQL-серверами одно из направлений.

С TDD разработкой к сожалению никогда не сталкивался, но по описанию я не особо могу представить ее применение в сфере 1с программирования ибо у нас как всегда нужен быстрый результат и желательно забесплатно.

Вот то что со своего опыта могу подтвердить или опровергнуть.
RainyAugust22; JesteR; burlakov; Algiz; wunderland; amon_ra; help1Ckr; vitalya24; +8 Ответить 1
21. Саша Безымяный (help1Ckr) 07.08.13 12:43
"Снижение рисков внезапного ухода ценного сотрудника, при условии документирования реализуемых проектов и задач.
Возможно, создать корпоративную wiki которая будет доступна с корпоративного сайт" бешено плюсую
22. Саша Безымяный (help1Ckr) 07.08.13 13:07
(20) GreenFox, "Но учебный SQL-сервер для экспериментов в самой фирме-франчайзи быть должен. Люди должны развиваться и изучение клиент-серверной архитектуры и взаимодействия с SQL-серверами одно из направлений. " - вот это хороший вопрос. Для написания запросов понимать как это все работает очень важно. Сам бы с удовольствим пошел бы на обучение по скль, а то часто упираюсь в незнание оного
23. Вячеслав Клюев (slavik27) 07.08.13 19:22
(18) vitalya24, все равно спасибо, интересно было бы описание такого опыта - создания с нуля и до какого-то практического результата!
24. evgen1977 (musatov1c.ru) 28.08.13 08:40
Хоть и работаю один, но все равно интересно :) Спасибо за ссылки. Из-за того, что пришел в сферу 1с из бухгалтерии, я немного не в теме про технологии программирования. Поэтому интересно именно с этой стороны :)
25. Анатолий (ABudnikov) 11.09.13 18:37
интересно было бы посмотреть на работающую wiki для 1С команд. Пока реально работающую - не встречал.
RainyAugust22; +1 Ответить 2
26. Евгений Сосна (pumbaE) 11.09.13 19:53
Тема TDD не раскрыта.
artbear; Taktic; romansun; +3 Ответить
27. qwertor (qwertor) 23.10.13 18:52
(25) ABudnikov, заверните поток работ по приемке\тестированию при передаче с разработке в эксплуатацию через документирование в вики и она получит наполнение и дальнейшую жизнь. OneNote+Sharepoint удобная альтернатива прочим веб-движкам.

п.8 интересная тема(шина) но все руки никак не доходят, кто что еще применял? ссылок не подкинете?

почему-то никак не затронут вопрос технологии проектирования архитектуры, в этом плане очень интересен СППР, кому нибудь удалось приручить этого монстра для повседневной работы? там же и управление требованиями и задачами разработчиков есть.
28. Роман Романов (romansun) 23.10.13 23:54
(25)
у нас работает... wiki и jira. JIRA используется обязательно и везде, wiki - по возможности. В обязательный документооборот не входит.

(27)
шины, вот как раз таки MQ мы внедряем... но заказчикам, соответственно :) Зачем её использовать разработчикам прям вот - эээ, я как-то не задумывался об этом ))))

Message Broker - это такое жОсткое решение для очередей сообщений в системах интеграции. Это используют в банках, во всяких платежных системах, страховых и т.п. Там масштабы миллионами транзакций. Гарантированная доставка и всё такое. Интересно было бы узнать, да, такой опыт для внутреннего потребления.

Про СППР я писал как-то уже на ИС. Очень трудоёмко. Если вы большие, пишите типовые коробки, у вас народ отделами прям сидит кодит, аналитит, тестит, то может быть имеет смысл внедрить. Иначе дорого. СППР - это отдельная фултайм загрузка и, возможно, что и не на одного человека.
29. Роман Романов (romansun) 23.10.13 23:56
Товарисчи, кто готов таки рассказать про ТДД, прям чтоб с примерами и трудозатратами в процентном отношении? ;)

А то все вокруг, да около...
30. Евгений Сосна (pumbaE) 24.10.13 00:48
(29) romansun, на сколько знаю на второй день 8 ноября в 3 зале будет Артур рассказывать и показывать на практике. Я пока лично пытаюсь использовать, получается вроде неплохо , но пока еще у меня всего около 200 тестов и не встречал ситуаций когда половина тестов перестает работать.

TDD - время увеличивается не пропорционально. С уверенностью могу сказать, что когда думаешь "а как я это буду тестировать" - прочищает мозги и поневоле делаешь декомпозицию.
31. Андрей Моисеев (nihfalck) 24.10.13 08:44
опять таки из методологии SCRAM


поправьте.

по списку - за исключением некоторых пунктов применимо и для создания "отдела автоматизации" при каком-нибудь предприятии.
32. Ruslan Edokov (Redokov) 27.10.13 20:22
(5) vitalya24,
Самая большая проблема ТДД в том, что для разработки теста, его сложность повторяет сложность покрываемого кода. В общем случае разработчику достаточно скопировать код теста и вставить в программу. Кроме того, большая часть ошибок тестированием не покрывается в принципе.
Это не значит, что тестировать не надо. Но не стоит делать из этого панацею. Хорошая статья есть у Дмитрия Завалишина (Digital Zone) на эту тему.
33. Ильдар Гайсин (gia2011) 20.12.13 17:00
не раскрыта тема оптимизации при модульном программировании
34. Артем Артеменко (dock) 23.12.13 19:47
В статье не хватает обзора инструментария. Конечно, по каждому пункту может получиться по отдельной статье... но ведь тогда и ценность информации вырастит в разы!
35. Елена Ситникова (lesenoklenok) 26.02.14 16:14
Тема достаточно интересная, но много чего не раскрыто. Но все равно спасибо большое.
36. Сергей Ширшаков (сер1) 05.12.14 18:19
Скорости работы команды программистов, аналитиков, техподдержки.

В каких единицах предлагаете измерять скорость работы?
37. SHiCK 06.04.15 08:48
Больше половины было у нас. Как тезисно статья на плохая. Но вот конкретики не хватает. Надеюсь на развернутую статью в будущем.
38. Денис Жуков (d.zhukov) 07.07.16 09:10
70% телодвижений, которые автор предлагает делать каждому руководителю в течении рабочего дня создают только видимость работы, имхо
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа