Дано: обычная госконтора, 10 человек программеров.
Сами себе постановщики задач, арихтекторы, кодеры, контроль качества и т.п. — всё в одном лице.
Кустарная разработка ПО, один программер — один проект. Взаимозаменяемости никакой. Опыта работы в команде нет.
Финансовой мотивации почти нет.
Про bug tracker, subversion понятия нет. Внедряю это с очень большим трудом ("у нас тут все на бумажечках записано").
Вопрос: что делать?
Набросайте умных слов по моему случаю для активного гугления, чтобы я мог сориентироваться с чего мне начать и продолжить.
Здравствуйте, tim4dev, Вы писали:
T>Вопрос: что делать?
Первый вопрос, на который надо получить ответ: надо ли что-то делать вообще?
Понятно, что прежний опыт может говорить — как это странно, ни баг-трекера, ни СКВ, ни тренингов-корпоративов.
Но, с другой стороны, никакие изменения не делаются просто так, типа "а чо, пацаны, давайте срочно код в subversion загрузим, а то как-то неправильно сейчас". Изменение ставит своей целью решить конкретную проблему.
Сформулируйте проблему(ы), ищите решения. "У них все неправильно" проблемой не является.
Здравствуйте, tim4dev, Вы писали:
T>Дано: обычная госконтора, 10 человек программеров. T>Сами себе постановщики задач, арихтекторы, кодеры, контроль качества и т.п. — всё в одном лице. T>Кустарная разработка ПО, один программер — один проект. Взаимозаменяемости никакой. Опыта работы в команде нет. T>Финансовой мотивации почти нет.
T>Про bug tracker, subversion понятия нет. Внедряю это с очень большим трудом ("у нас тут все на бумажечках записано").
T>Вопрос: что делать?
T>Набросайте умных слов по моему случаю для активного гугления, чтобы я мог сориентироваться с чего мне начать и продолжить.
T>Спасибо.
Здравствуйте, rlabs, Вы писали:
R>Здравствуйте, tim4dev, Вы писали: T>>Вопрос: что делать? R>Первый вопрос, на который надо получить ответ: надо ли что-то делать вообще?
Надо.
R>Понятно, что прежний опыт может говорить — как это странно, ни баг-трекера, ни СКВ, ни тренингов-корпоративов. R>Но, с другой стороны, никакие изменения не делаются просто так, типа "а чо, пацаны, давайте срочно код в subversion загрузим, а то как-то неправильно сейчас". Изменение ставит своей целью решить конкретную проблему.
Там не только "пацаны", там и старые и малые, все в куче.
Указаные продукты внедряются с конкретными целями. Багзилла — чтобы сделать процесс прозрачным и документируемым. Svn — как минимум для бэкапов исходников, хотя бы так на первых порах.
Но что еще можно улучшить в этих условиях, я имею в виду в какую сторону копать (конкретные howto мне не нужны, сам придумаю) ? Что почитать (книжек много) ?
R>Сформулируйте проблему(ы), ищите решения. "У них все неправильно" проблемой не является.
Так вопрос не ставится. Формулировать и искать решения хочется на научной основе.
Валить.
Оставаться имеет смысл только если вам действительно интересно начать организовывать процесс разработки ПО.
Спасибо вам за это скажут не скоро (если вообще скажут), и геморроя наживете массу.
Лучше уйти туда, где процесс уже организован и эффективно там работать.
Поддержать естественный отбор по отмиранию "неэффективных" контор вместе с их руководством.
T>Указаные продукты внедряются с конкретными целями. Багзилла — чтобы сделать процесс прозрачным и документируемым. Svn — как минимум для бэкапов исходников, хотя бы так на первых порах.
Ок, мое частное мнение: вы встретите _невероятное_ сопротивление команды, пытаясь заставить их делать что-то без объяснения, зачем им это надо. "Сделать процесс прозрачным" — это сферическая цель в вакууме. Она не нужна ни вашим коллегам, ни вашим заказчикам. В такой постановке никакая задача не решается, и профита никому не приносит.
Полагаю, сейчас меня реальные ПМы начнут яростно опровергать. Научных обоснований у меня нет, так что я на этом, пожалуй, дискуссию закончу.
Спасибо.
Я форум начал читать, но до 2008 еще не дошел.
Взято из треда, как про нас написано :
>"Все хотелки заказчика получаются устно и нигде не регистрируются. Обычно хотелки появляются ближе к концу проектов и иногда звучат примерно так: "Все >что вы написали — это все нам н###й не нужно! Переделайте все не знаю как, но чтобы было по другому!" >Нет процесса разработки архитектуры. То есть первоначально архитектура высасывается из пальца, а по мере разрастания проектов прикручиваются >всевозможные костыли. Хуже всего что все архитектурные решения нигде не документируются. >Проектной документации — нет вообще. Тестирование — на уровня тыкания по менюшкам. Отсутствует планирование как таковое. Все сроки высасываются из >пальца. > >На выходе: >Продукты плохого качества, без документации, без возможности нормальной поддержки и масштабирования. Процесс написания абсолютно не предсказуем. > >Чего хочется: >Поднять качество продукта, кода, документации. Сделать процесс предсказуемым и управляемым. > >Вопросы: >Что вообще делать в таких случаях? Может ли помочь введение формальных методологий разработки, или лучше оставить пациента доживать последние дни?"
Только с поправкой что "4 тестировщика; 3 технических руководителя проекта" у меня нету.
Здравствуйте, tim4dev, Вы писали:
T>Дано: обычная госконтора, 10 человек программеров. T>Сами себе постановщики задач, арихтекторы, кодеры, контроль качества и т.п. — всё в одном лице. T>Кустарная разработка ПО, один программер — один проект. Взаимозаменяемости никакой. Опыта работы в команде нет. T>Финансовой мотивации почти нет.
Извиняюсь, не раскрыл свою позицию. Скорее всего, вам не дадут наладить процесс. Вы можете строить 10 процессов (по одному на программера), но как только захотите собрать команду, то ввиду того, что команда не сможет заниматься 10ю проектами одновременно, начальство начнет совать палки в колеса, сколь благородны бы ни были ваши цели. Отрыв от кодирования людей для решения других задач (архитектуры, контроль качества и т.п.) приведет к такому же результату.
В общем, прежде чем начать строить процесс, настойчиво рекомендую обсудить с руководством тот процесс, какой вы видите, и сколько проектов за единицу времени можно будет выполнять, имея такой процесс.
Здравствуйте, rlabs, Вы писали:
R>Здравствуйте, tim4dev, Вы писали:
T>>Указаные продукты внедряются с конкретными целями. Багзилла — чтобы сделать процесс прозрачным и документируемым. Svn — как минимум для бэкапов исходников, хотя бы так на первых порах.
R>Ок, мое частное мнение: вы встретите _невероятное_ сопротивление команды, пытаясь заставить их делать что-то без объяснения, зачем им это надо. "Сделать процесс прозрачным" — это сферическая цель в вакууме. Она не нужна ни вашим коллегам, ни вашим заказчикам. В такой постановке никакая задача не решается, и профита никому не приносит.
Без объяснения я не делаю, объясняю. Возможно "прозрачность" — это туманно, попробую перефразировать: чтобы не терялись заявки на доработку ПО и контролировалась, документировалась разработка нового. В планах внедрения — wiki или trac.
Потому как сейчас — все на бумажках, уволился прогер — всё, концы в воду.
R>Полагаю, сейчас меня реальные ПМы начнут яростно опровергать. Научных обоснований у меня нет, так что я на этом, пожалуй, дискуссию закончу.
Здравствуйте, samius, Вы писали:
S>Извиняюсь, не раскрыл свою позицию. Скорее всего, вам не дадут наладить процесс. Вы можете строить 10 процессов (по одному на программера), но как только захотите собрать команду, то ввиду того, что команда не сможет заниматься 10ю проектами одновременно, начальство начнет совать палки в колеса, сколь благородны бы ни были ваши цели. Отрыв от кодирования людей для решения других задач (архитектуры, контроль качества и т.п.) приведет к такому же результату.
Одну команду я не буду собирать. Потому что она не соберётся, это 100%. И руководство не пойдет на это, потому что это будет им непонятно.
Да и прироста производительности тоже не получится.
Хотя, м.б., какая-нибудь мысль и вызреет, может попарно. Но это на очень далекую перспективу.
Ситуация, я думаю , типична. Сидит прогер, ваяет нетленку. Тут срочная бумажка — переделать в таком-то АРМе то-то. Ну, и т.д.
Так чтобы велась разработка одного-двух проектов, не было и не будет.
S>В общем, прежде чем начать строить процесс, настойчиво рекомендую обсудить с руководством тот процесс, какой вы видите, и сколько проектов за единицу времени можно будет выполнять, имея такой процесс.
Я это вИдение процесса еще создаю, если можно так сказать.
Здравствуйте, RGB_Dart, Вы писали:
T>>Вопрос: что делать?
RGB>Валить. RGB>Оставаться имеет смысл только если вам действительно интересно начать организовывать процесс разработки ПО. RGB>Спасибо вам за это скажут не скоро (если вообще скажут), и геморроя наживете массу. RGB>Лучше уйти туда, где процесс уже организован и эффективно там работать.
Здравствуйте, tim4dev, Вы писали:
T>Набросайте умных слов по моему случаю для активного гугления, чтобы я мог сориентироваться с чего мне начать и продолжить.
Попробовать разобраться, что же такое SDLC — Software Development Life Cycle, и как его логически внедрить в ваших условиях. Внедрять системы по одной, не имея понятия, как они каждая и вместе влияют на процесс -- пустая трата времени и сил. Все участники процесса должны понимать, зачем нужна та или иная автоматизация, тогда и решение качественнее, и живет дольше, и работать становится интереснее...
Здравствуйте, tim4dev, Вы писали:
T>Я это вИдение процесса еще создаю, если можно так сказать.
Ты создаешь видение сферического процесса в вакууме. Этот сферический процесс в вакууме не нужен ни твоему руководству, ни коллегам.
Попробуй сформулировать четко и однозначно ответы на вот такие вопросы:
1. В чем недостатки существующего процесса/технологии разработки? Какие убытки несет (гос)контора от этих недостатков? (Хотя на убытки скорее всего всем начхать.)
2. Какие недостатки закроет/покроет новый процесс?
3. Сколько времени и денег (как минимум зарплата*время) потребует внедрение нового процесса?
4. Какие профиты принесет новый процесс за счет п.2? Как быстро эти профиты покроют убытки, понесенные по п.3?
5. Кому из твоего руководства это надо с учетом п.4? А кому — не надо?
Здравствуйте, Vlad_SP, Вы писали:
V_S>Ты создаешь видение сферического процесса в вакууме. Этот сферический процесс в вакууме не нужен ни твоему руководству, ни коллегам.
V_S>Попробуй сформулировать четко и однозначно ответы на вот такие вопросы: V_S>1. В чем недостатки существующего процесса/технологии разработки? Какие убытки несет (гос)контора от этих недостатков? (Хотя на убытки скорее всего всем начхать.) V_S>2. Какие недостатки закроет/покроет новый процесс? V_S>3. Сколько времени и денег (как минимум зарплата*время) потребует внедрение нового процесса? V_S>4. Какие профиты принесет новый процесс за счет п.2? Как быстро эти профиты покроют убытки, понесенные по п.3? V_S>5. Кому из твоего руководства это надо с учетом п.4? А кому — не надо?
6. Какие риски снимаются\уменьшаются и сколько это может (а значит будет, рано или поздно) стоить, если оставить как есть.
Правда есть чувство, что про риски немного преждевременно разговаривать в такой ситуации, тем более что госконтора... Тем не менее понимать начинать уже пора. И думать, как подать это руководству, с тщательным учетом п.5 — готовить почву (например, помочь непосредственному рук-ву представить Ваши инициативы наверх и объяснить как получить свою часть лавров в случае успеха). Возможно, стоит припомнить какие-то инциденты из прошлого (сработавшие риски) и\или придумать и обсчитать наиболее вероятные из будущего (пока не сработавшие).
Стандартные примеры: серьезно заболел\ушел человек — унес сакральное знание — плюс столько-то человеко-часов\дней\недель задержки релиза. Упало что-то — пропало что-то — плюс ресурсы на восстановление. Не было записей\потеряли — поняли что в итоге забыли что-то — плюсуем часы на воспоминания.
И так по каждому варианту — прикинуть вероятность наступления\периодичность и потенциальные убытки на исправление\восстановление в часовом эквиваленте (не в деньгах. наверху сами посчитают в чем нужно), для лучшего понимания степени серьезности. А затем получившуюся цифру сравниваем с 3 и предлагаем рук-ву вместе подумать что реально нужно, а что может потерпеть.
Как правило больших мозгов сравнить цифры разных порядков не требуется Уже заручившись поддержкой рук-ва (а не наоборот), можно думать о том как подать это коллегам и в чем будет их персональная выгода от Ваших рацпредожений.
съэкономил-предусмотрел = заработал. Можно бороться не столько за увеличение дохода (тем более вряд ли это зависит от технического специалиста напрямую, так что Вашу заслугу в повышении продаж потом еще нужно будет серьезно поискать да и кто Вам расскажет выросли ли реальные доходы), а всего лишь разобраться с ненужными потерями уже там, где ответственность на Вас — и это даст гораздо больше, чем пара дополнительных продаж (которых еще может и не быть даже с отличным процессом, а потери-убытки — как правило вот они, можно щупать). Плюс бывает проще сравнить показатели до и после — что также хорошо для карьеры. Впрочем, это уже немного оффтоп.
PS И лучше не пытайтесь объять необъятное — инициативы толкайте не сразу по всем направлениям и одновременно, а точечно и поэтапно, по порядочку. Сначала добиваясь если не поддержки, то хотя бы понимания большинством участников процесса — как правильно многие уже заметили выше. Так всем будет спокойнее и проще.
PPS Да, еще: революций не обещайте и не требуйте — а лучше все преподносите под видом небольших (но жизненно необходимых!) изменений (тем более в Вашей ситуации это так и есть), от которых жизнь станет просто прекрасной, причем для тех кому Вы это "продаете" И далее идут доводы в поддержку, согласно пунктам выше и другим грамотным рекомендациям коллег по ветке\форуму
... << RSDN@Home 1.2.0 alpha 4 rev. 1136>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, tim4dev, Вы писали:
T>Про bug tracker, subversion понятия нет. Внедряю это с очень большим трудом ("у нас тут все на бумажечках записано").
T>Вопрос: что делать?
А вы какое-нибудь начальство, или рядовой программист, один из этих 10-и?
Здравствуйте, tim4dev, Вы писали:
T>Потому как сейчас — все на бумажках, уволился прогер — всё, концы в воду.
так это всех (кроме вас) устраивает? я не уверен, что надо что-то делать.
1) ищите поддержку в группе и у _начальства_ по поводу недовольства текущей ситуацией.
2) составте анализ _прошлых_потерь_ (финансовых и репутационных) от сложившейся ситуации. покажите начальству.
3) ни в коем случае не выносите вопрос на заказчика. похоронят всей командой.
4) начните сами работать так, как вы считаете правильным. найдете сторонников — сможете двигать в общем направлении.
5) составте план (ну вот как вы здесь написали в начале) из нескольких ясно-понятных пунктов, распечатайте его крупными буквами и повесте над _вашим_ столом.
...если вы не уволитесь в течении 4-6 месяцев, то вас сделают руководителем. во
Здравствуйте, tim4dev, Вы писали:
T>Дано: обычная госконтора, 10 человек программеров. T>Сами себе постановщики задач, арихтекторы, кодеры, контроль качества и т.п. — всё в одном лице. T>Кустарная разработка ПО, один программер — один проект. Взаимозаменяемости никакой. Опыта работы в команде нет. T>Финансовой мотивации почти нет.
1) Обыграть весь отдел в CS по сетке. Или у вас там HL предпочитают? Короче приобрести уважение коллег.
2) Прокинуть ненавязчиво самому умному из коллег мысль -- а чего это мы с тобой как лохи без svn. Объяснить что такое svn, поставить на двоих, обучить его пользоваться и снисходительно поглядывать на весь остальной отдел до возникновения у всех тоже мыслей, а что это они круче нас что ли.
3) На посиделках с водкой в рабочее время (viva la госконтора) долго трепаться о том как это круто -- система багтрекинга и сколько времени для CS она освободит.
4) Поставить систему багтрекинга себе и тому умному коллеге который уже разобрался в svn
5) Устраниться. Заниматься своей работой, регулярно обыгрывать всех в CS, пить в обеденный перерыв водку с начальством и давить ему на мозги тем как это круто -- у вас в отделе багтрекинг. Ждать пока остальные обольются слюной и тоже начнут ставить себе svn и багтрекинг. Дистрибутивы должны быть расшарены в общеизвестном месте и литература должна лежать на доступной для всех полочке.
Вот примерно так в госконторе безо всякой финансовой мотивации можно за месяц ввести svn, багтрекинг и выстроить хорошие отношения с начальством и подчинёнными.
Здравствуйте, Tilir, Вы писали:
T>Вот примерно так в госконторе безо всякой финансовой мотивации можно за месяц ввести svn, багтрекинг и выстроить хорошие отношения с начальством и подчинёнными.
Все здорово, пока svn и багтрекинг (а главное — сервер под них) не пришлось согласовывать с режимным подразделением.
P.S. CS с ними без вопросов согласовывается, а вот что для работы — сложнее.
Поскольку насчет сферической цели в вакууме — ты совершенно прав.
