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

04.08.13

Управление проектом

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


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

 

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

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

20.12.2023    2734    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14237    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5824    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4660    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2734    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4153    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10597    0    biimmap    79    

73

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13030    0    Evil Beaver    17    

116
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. пользователь 04.08.13 12:04
Сообщение было скрыто модератором.
...
2. пользователь 04.08.13 12:08
Сообщение было скрыто модератором.
...
3. romansun 193 04.08.13 12:56 Сейчас в теме
да не, всё так...

можете рассказать, что используете/пробовали в качестве:
- систему управления ресурсами
- системы учета задач
- wiki
- чуть подробнее про TDD: как, что, по чем, примеры :)
Taktic; help1Ckr; +2 Ответить
5. vitalya24 233 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) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам.

По факту применимо при больших проектах когда одна группа разработки не знает что делает другая...
В более мелких тз более применимо разработка в две руки если это позволяет человеческий ресурс.
user1609888; +1 1 Ответить
8. romansun 193 04.08.13 15:36 Сейчас в теме
(5)
Меня вот во всей этой теме интересует больше всего тестирование таки. К примеру, как вы оцениваете трудоёмкость при TDD, ведь, по идее, она должна возрастать в разы... Как сами разработчики относятся к TDD и ко всем сопутствующим сложностям? Пишите какие-либо приспособы для прогонки тестов?

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

По поводу остального - да, со всем согласен. Мы используем JIRA и, соответственно, Confluence. Trello еще тоже местами. Ну и всякого разного по мелочи...
10. vitalya24 233 04.08.13 16:54 Сейчас в теме
(8) romansun, как-то много времени уделил этому вопросу. Среди прочих программ были Сценарное тестирование из КИП, и разработки ИБМ для создания сценариев тестирования. Попробую уделить время и изложить мысли...
32. Redokov 81 27.10.13 20:22 Сейчас в теме
(5)
Самая большая проблема ТДД в том, что для разработки теста, его сложность повторяет сложность покрываемого кода. В общем случае разработчику достаточно скопировать код теста и вставить в программу. Кроме того, большая часть ошибок тестированием не покрывается в принципе.
Это не значит, что тестировать не надо. Но не стоит делать из этого панацею. Хорошая статья есть у Дмитрия Завалишина (Digital Zone) на эту тему.
4. kompas-dm 780 04.08.13 13:15 Сейчас в теме
(0) Где-то 70 годы. Так и было.
6. PAVI 1388 04.08.13 13:43 Сейчас в теме
Тоже из опыта:
1. Еженедельный семинар проводился в офисе фирмы-франчайзи (так удобнее начальству), вечером (чтобы сэкономить рабочее время). А я к вечеру уже никакая...
2. Групповое размещение в фирме-Заказчик было столь плотным, что когда один член команды хотел пи-пи, вставать должны были человек 5.
3. Прямой доступ к 1С и серверам?! Честное слово, если вы сторонний разработчик, то от этого лучше открещиваться, иначе вас будут обвинять во всех смертных грехах.
4. Обучение базовым навыкам конфигурации специалистов техподдержки...И это бывало, но достает, когда одно и то же в 20-й раз. Хорошо еще, если с новым человеком. А когда этот спец имеет другое мнение о своих должностных обязанностях и на мнение начальства и твои старания ему...
Taktic; fuxic; zse; vitalya24; +4 1 Ответить
7. vitalya24 233 04.08.13 13:48 Сейчас в теме
(6) PAVI, все зависит от организации, реализации, можно и суп так сварить что технически это будет суп, а есть его нельзя будет:)
9. ivanov660 4325 04.08.13 15:44 Сейчас в теме
Хорошая подборка директив - особенно подходит для внутренних отделов больших компаний. Однако, в отечественных реалиях некоторые пункты не выполнимы из-за современного менталитета, к сожалению. Это касается "базы знаний", рефакторинга кода и других пунктов в большей или меньшей степени.
14. vitalya24 233 05.08.13 10:58 Сейчас в теме
(9) ivanov660, как ни странно база знаний у нас есть, штат отдела праммного направления примерно 40 чел...
11. пользователь 04.08.13 22:20
Сообщение было скрыто модератором.
...
12. vitalya24 233 05.08.13 10:41 Сейчас в теме
(11) Eugeneer, странно, а что вам не понятно? это всего лишь рекомендации на основе личных наблюдений, большинство из которых успешно внедрено. Если недостаточно инструментария то я могу описать.
13. vitalya24 233 05.08.13 10:56 Сейчас в теме
(11) Eugeneer, кстати, некоторое время изучал такое направление как разработка ИТ-стратегии бизнеса, и пришел в выводу что очченнь немногие компании занимаются написанием такого документа, хотя имеют большой штат ит-специалистов. Я согласен что реалии жизни немного отличны от "сферического коня в вакууме", но например первое из предложенного списка, заимствованное из метологии скрам, нам помогло...
15. borodabmc 06.08.13 12:48 Сейчас в теме
По статье - практически все, что описано есть у нас! Спасибо, за то, что обратили внимание на данную тему!

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


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

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

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

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

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

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

Вот то что со своего опыта могу подтвердить или опровергнуть.
Yakud3a; RainyAugust22; JesteR; burlakov; Algiz; wunderland; amon_ra; help1Ckr; vitalya24; +9 Ответить
22. help1Ckr 07.08.13 13:07 Сейчас в теме
(20) GreenFox, "Но учебный SQL-сервер для экспериментов в самой фирме-франчайзи быть должен. Люди должны развиваться и изучение клиент-серверной архитектуры и взаимодействия с SQL-серверами одно из направлений. " - вот это хороший вопрос. Для написания запросов понимать как это все работает очень важно. Сам бы с удовольствим пошел бы на обучение по скль, а то часто упираюсь в незнание оного
21. help1Ckr 07.08.13 12:43 Сейчас в теме
"Снижение рисков внезапного ухода ценного сотрудника, при условии документирования реализуемых проектов и задач.
Возможно, создать корпоративную wiki которая будет доступна с корпоративного сайт" бешено плюсую
24. musatov1c.ru 6 28.08.13 08:40 Сейчас в теме
Хоть и работаю один, но все равно интересно :) Спасибо за ссылки. Из-за того, что пришел в сферу 1с из бухгалтерии, я немного не в теме про технологии программирования. Поэтому интересно именно с этой стороны :)
25. ABudnikov 3 11.09.13 18:37 Сейчас в теме
интересно было бы посмотреть на работающую wiki для 1С команд. Пока реально работающую - не встречал.
Serg O.; RainyAugust22; +2 Ответить
27. qwertor 23.10.13 18:52 Сейчас в теме
(25) ABudnikov, заверните поток работ по приемке\тестированию при передаче с разработке в эксплуатацию через документирование в вики и она получит наполнение и дальнейшую жизнь. OneNote+Sharepoint удобная альтернатива прочим веб-движкам.

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

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

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

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

Про СППР я писал как-то уже на ИС. Очень трудоёмко. Если вы большие, пишите типовые коробки, у вас народ отделами прям сидит кодит, аналитит, тестит, то может быть имеет смысл внедрить. Иначе дорого. СППР - это отдельная фултайм загрузка и, возможно, что и не на одного человека.
26. pumbaE 11.09.13 19:53 Сейчас в теме
Тема TDD не раскрыта.
artbear; Taktic; romansun; +3 Ответить
29. romansun 193 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


поправьте.

по списку - за исключением некоторых пунктов применимо и для создания "отдела автоматизации" при каком-нибудь предприятии.
33. gia2011 20.12.13 17:00 Сейчас в теме
не раскрыта тема оптимизации при модульном программировании
34. dock 44 23.12.13 19:47 Сейчас в теме
В статье не хватает обзора инструментария. Конечно, по каждому пункту может получиться по отдельной статье... но ведь тогда и ценность информации вырастит в разы!
35. lesenoklenok 35 26.02.14 16:14 Сейчас в теме
Тема достаточно интересная, но много чего не раскрыто. Но все равно спасибо большое.
36. сер1 26 05.12.14 18:19 Сейчас в теме
Скорости работы команды программистов, аналитиков, техподдержки.

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