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. Ввести Систему управления человеческими ресурсами
- Карточка каждого сотрудника.
- Динамика развития.
- График тренингов и развития сотрудника. Не развивающиеся сотрудники не нужны компании.
Профессиональная направленность сотрудника. Приоритетные направления.
- Периодические тестирования и повышения квалификации сотрудников.
- Загрузка команды и отдельного сотрудника.
10.Ввести систему для учета задач
- Отслеживания прогресса завершения задач.
- Скорости работы команды программистов, аналитиков, техподдержки.
- Скорости работы отдела разработки, эффективности сотрудников, проблемных задач, использование такой аналитики для планирования.
- Прогнозирование мощности/ресурса нагрузки работы команд и отдела разработки в целом
- Выявление эффективности сотрудников
- Входные данные для системы управления человеческими ресурсами.
11.Профилирование сотрудников, проектных команд.
- Выявление эффективности сотрудников, программистов в определенных отраслях или направлениях разработки, перераспределение задач между программистами, создание профильных команд, профильная команда работает воодушевленно более эффективно.
- Проведение опроса или тестирования программистов на предмет того с чем он работал, что более нравиться, для определения направленности, предпочтения программистов.
12.Разработка через тестирование.
- Донести до разработчиков методику разработки TDD, разработка через тестирование. (как должно работать - разработка - Рефакторинг)
13.Введение локальной wiki компании.
- Обмен информацией.
- Инструкции, корпоративные документы, особенности работы систем, специфика работы узлов (1с, не 1с), модулей.
- Упростит обмен информацией между существующими сотрудниками и значительно ускорит скорость входа полноценный рабочий режим работы новых сотрудников, не затрачивается время опытных сотрудников на обучение новых.
- Простое добавление новой информации, простой поиск.
- Снижение рисков внезапного ухода ценного сотрудника, при условии документирования реализуемых проектов и задач.
- Возможно, создать корпоративную wiki которая будет доступна с корпоративного сайт
, но пока еще у меня всего около 200 тестов и не встречал ситуаций когда половина тестов перестает работать.
