Цитата(velkarn @ Dec 16 2012, 17:22)
Добрый день!
Интересует субж при разработке электронных устройств (в основном только железо, без ПО).
Посоветуйте пожалуйста статьи/ресурсы по инженерному менеджменту, а также планированию.
есть и конкретные вопросы, мож кто ответит, если не трудно (расскажите как это всё у вас устроено)
1 пишутся ли у вас понедельные отчеты (отчеты о выполненной работе за каждый день)?
2 зависит ли зп от объёма выполненной работы?
3 (работаю на совдепиевском предприятии) у нас в плане "разработка схемы" стоит одной строкой и не подлежит дальнейшей детализации, мне кажется это не очень верно)) а какая детализация этого у вас?
Вставлю свои "пять копеек".
У нас (конструкторский отдел радиозавода, по сути, порядки остались "совдеповские") для соблюдения формальной стороны вопроса, и как дань традиции, пишутся месячные планы, потом отчеты. Хотя они, чаще всего, только для великого начальства и живут немного в параллельной реальности. (начальству об этом говорить не принято) Сначала меня это жутко нервировало, потом, как и все, махнул рукой и перестал обращать внимание.
Для реальной работы, по ряду проектов, где-то с 2011г. стали применять Atlassian Jira,как систему управления заданиями, в связке с SubVersion для хранения документации.
Вся документация по проекту хранится в репозитории SVN (дерево папок повторяет структуру и состав изделия с разбивкой по блокам, платам и т.п.) Под контролем версий лежат схемы, PCB, чертежи DWG, исходники программ, и документация (в форматах RTF или Word). Конечно, большинство этих файлов SVN воспринимает как просто бинарные и "не умеет" отслеживать и сливать их изменения. Тут уж приходится чисто организационно решать вопрос чтоб один и тот же файл не правили два исполнителя одновременно. На практике таких проблем не возникало. Большинство документации и текстовых файлов (когда нужна групповая работа над документом) писалась в GoogleDoc, а потом результат вставлялся в репозиторий уже в RTF или DOC.
Теперь по заданиям.
Хотя Jira и не идеальный инструмент для работы с железом - все же он "родом" из багтрекера - но ее использование сильно упростило жизнь и позволило хоть как-то упорядочить работу.
Для проекта в Jir'е создавался набор компонентов с разбивкой по блокам, платам, ПО и т.д. Все задания привязываются к компоненту, с которым они связаны. Устанавливаются логические связи между задачами, которые соответствуют реальной связи узлов/плат/блоков в изделии.
Пример набора задач, например, для платы:
* Предварительный расчет (если какие-либо узлы требуют расчета для выбора той или иной схемотехники)
* Разработка схемы (тут, если схема сложная и может быть разделена на логически законченные куски, для каждого могут быть созданы отдельные подзадачи)
* Разработка печатной платы
* Сопровождение комплектования платы. (Комплектование ведет отдел снабжения, но все вопросы с которыми они обращались к нам, конструкторам фиксировались тут)
* Монтаж платы или Сопровождение монтажа платы (т.к. у нас собственно монтажный участок в систему вовлечен не был, эту задачу вел конструктор, отвечающий за плату. Тут фиксировались все вопросы возникающие при проведении монтажа, все обнаруженные ошибки в документации и пр.)
* Ну и собственно, запуск и регулировка платы - журналируется весь процесс с указанием возникших проблем и пути которым они решались.
В каждой задаче, в ленте комментариев, пишется своего рода журнал работы: Сделал то-то, получилось так-то, параметры нас не удовлетворяют - варианты решения, проверил такой-то вариант - не получилось, проверил второй вариант - параметры нормальные и т.п. В результате имеем ход работы, фиксацию проблем с которыми столкнулся исполнитель и почему он принял то или иное решение. Бывали случаи, что разрабатывал схему один, а запускать пришлось другому человеку - вот тут и была оценена вся полезность подобной системы.
Исполнитель, в процессе выполнения работы, желательно ежедневно, проставляет затраченное время на конкретную задачу. Процессы разработки схемы или запуска платы, зачастую, трудно прогнозируются по времени, но исполнитель имеет возможность сам ставить процент готовности по его мнению. Для руководителя это удобно для быстрой оценки состояния дел по проекту. Если возникают сомнения, то просмотр журнала затраченного времени совместно с лентой комментариев (где описан ход работы) очень легко вычисляется если исполнитель "вешает лапшу" или действительно столкнулся с проблемой которая с ходу не решилась. В любом случае, при любых разборках, разговор становится аргументированный - есть четка хронология работы и временных затрат.
Самой большой проблемой внедрения стал "человеческий фактор".
Именно потому, что стало нельзя заявить что схема слишком сложная и на ее разработку нужно два месяца и месяц из них проиграть в "тетрис". народ сопротивлялся как мог. "Мы тут *дцать лет работали без нее, накой она нам надо!" Но со временем плюсы все же пересиливают.
Еще один момент - если в процессе работы фиксировать ее ход, то возникает ощущение, что "я быстрее сделаю чем буду тут писать". Отчасти оно так и есть - работа замедляется. Но по прошествии времени, нюансы часто забываются, и сталкиваясь с подобной задачей или проблемой повторно ты снова тратишь время на ее решение, вместо использования прошлого опыта своего или коллег. Например в изделии А применен некий модуль. Изделие успешно сдано и выпускается. Потом, в изделии Б решили снова применить этот модуль, но человек который с ним работал уволился или уже основательно все забыл. В итоге, приходится заново разбираться с применением данного модуля, программированием режимов, экспериментировать и т.п.
Ну как-то так - несколько сумбурно изложил, но, думаю, основная мысль ясна.
Организация работы в коллективе разработчиков.
Dec 16 2012, 10:12
