Как осуществляется взаимодействие в команде разработчика софта?

Хочу Стартап, есть деньги. Нет СТО. Собственно я хотел бы узнать, как осуществляется взаимодействие в команде разработчика софта. Начиная от Проджект Менеджера и спускаясь по вертикали и горизонтали.
 Как программисты, тестировщики, дизайнеры взаимодействуют между собой? Какой софт используется для взаимодействия?
— Как ставятся задачи (BaseCamp или что-то более специальное используется)?
— Как контролируется выполнение задач (нужен ли для этого специфический софт)?
— Что используется для тестирования софта?
— Какие рычаги управления командой?
— Как происходит замена (временная или постоянная) людей в случае если они элементарно заболели?
— Как осуществляется хранения информации?
— Как защищается код от копирования и выноса? И нужно ли вообще переживать по этому поводу?
— Нужно ли приобретать железо в офис? Если точнее нужно ли покупать MACS для своих сотрудников или разрешить работать на своих?

Я безгранично благодарен всем, кто потратит время отвечая на мои странные вопросы без оффтопа. Очень большое спасибо! :) Буду рад ссылкам на необходимое инфо, при этом ваши ответы также супер необходимы.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Как программисты, тестировщики, дизайнеры взаимодействуют между собой? Какой софт используется для взаимодействия?
я повидал от никак до полного дня разговоров, софт... какой-нибудь трекер например джира и вики система например конфлюенс
Как ставятся задачи (BaseCamp или что-то более специальное используется)?
я получал задачи от поставленной устно до глубоко описанной с многостраничной специфиацией, тут уж раздолье как хочется или можется
Как контролируется выполнение задач (нужен ли для этого специфический софт)?
мне как разработчику это все равно, бывают разные подходы либо есть человек который шляется уточняет это у всех, бывает раз в день/неделю/месяц надо заполнить отчет, бывает надо заполнить почасовые отчеты, бывает не контролируется, забавно что чем больше контроль, тем меньше программисты успевают сделать, во всяком случае для фирмы до 50 программистов
Что используется для тестирования софта?
тестеров :) программы они знают, нафиг им мешать если сам не знаешь?
Какие рычаги управления командой?
бить :)
Как происходит замена (временная или постоянная) людей в случае если они элементарно заболели?
ну если все плохо и человек незаменимый, то никак, если человек заменимый, то проблемы нет, увольнять незаменимых единственное решение
Как осуществляется хранения информации?
репозиторий... гит/свн/меркуриал
Как защищается код от копирования и выноса? И нужно ли вообще переживать по этому поводу?
от дурачков можно защитится написать соглашением что мол подсудное дело, на самом деле ничего хорошего в таком суде не светит, можно забрать интернет, доступ к юсб и т.д. чтобы просто физически не могли, все страдают и ругаются только, к тому же появляются доп расходы т.к. инет нужен, надо как-то ухитрятся начинается разрастание штата админов и расширение их круга задач, можно просто давать доступ не на все и компоненты друг без друга не представляются особой ценности

вообще это глупая затея, т.к. ценности код не представляет для посторонних, его суппортить надо, что так накручено посторонние не знают и проще свое писать с нуля, чем чужое разбирать, другое дело если это например исходники виндовса :) но считать что твое творение когда-то таким станет — глупость и высокомерие, проще не защищать и хорошо относится к сотрудникам — и волки сыты, и овцы целы

Нужно ли приобретать железо в офис? Если точнее нужно ли покупать MACS для своих сотрудников или разрешить работать на своих?
конечно нужно и разрешить работать со своих и разрешить рабочие маки носить с собой, если очень просят

Благодарю за ответ! Продолжаю гуглить :)

Хочу стартап :) Ларису Ивановну хочу...

Якщо команда невелика, то я б радив взяти за основу Екстремальне Програмування (XP), та побудував процес виключно по ньому. Потім вже додав чисто адміністративних фіч. XP дасть вам відповіді на половину ваших запитань. Доречі, ця методика може надати вам можливість скоротити витрати на тестування.

Ще одне. Ніколи не намагайтеся вирішувати ті адміністративні проблеми, яких ще не існує. Це зайва витрата грошей без позитивного ефекту.

А тепер уявіть собі на хвилиночку. Людина, яка задає питання на кшалт

Как программисты, тестировщики, дизайнеры взаимодействуют между собой?
дослухався Вашої поради, найняв «невелику команду» і дав їй вказівку -"ану всі працюємо згідно з моделью XP«. Як ви гадаєте — через скільки тижнів він почне «додавати до них адміністративних фіч», а ще через скільки тижнів він зрозуміє, що всі його грошики вже розтринькані, а продукту нема і вже не буде?
Про
ніколи не намагайтеся вирішувати ті адміністративні проблеми, яких ще не існує.
— порада звісно слушна, але скажіть, яке з перерахованих ТС питань не є адмімністративним, та таким, котрі не потребують вирішення на почату — а скоріше ДО початку — роботи над проектом? Ну, хаба що не варто
переживать по этому поводу

Якщо людина не прочитає книжку або не займеться анаізом інструментів, які згадають тут, то будь яка порада не піде на користь. Отже, спочатку думаємо головою, а потім робимо.

XP дозволяє уникнути базових проблем управління, це майже готове рішення, яке суттєво мінімізує витрати. Навіть якщо мавпити один до одного все, що написано в книжках

Дякую, що відповіли серйозно на моє запитання!

Большое спасибо Виктор, что не оставили мои вопросы без внимания и ответили по теме без лишней критики.

специализорованный тестерский инструментарий
 — если сможете указать названия, я смогу углубиться в изучении инфо. Заранее спасибо!
систем управления версиями
 — какие вы считаете стоит использовать? Если из личного опыта, буду еще раз благодарен! Может есть какие то бесплатные? Или лучше на них не надеяться?
Тут тебе надо бы начать, а потом уже появиться более конкретные, на них можно ответить четче.
— Так и задумал. Чаще всего я самостоятельно ищу инфо, в этот раз решил действовать по другому. Но цель, действительно, чтобы за что-то ухватиться.

Еще раз спасибо!

Вот, уже конкретнее. На пару дней чтива набрался. Думаю будут еще вопросы, если позволите буду задавать в личку.

Готов в полной мере ответить на эти и другие сопутствующие вопросы, поделиться практическим опытом и поддерживать проект в тонусе, в обмен на интересный оффер от вашей компании.

Sergio здорово! О проекте напишу чуть позже. Буду рад вашему вниманию, комментариям.

Похоже, текст был переведен автопереводчиком.
Я не слышал про стартап, который достиг успеха благодаря четким и формализованным процессам. Стартап — это когда условия постоянно меняются, каждому приходится выходить за пределы зоны ответственности(а также — за пределы зоны комфорта). Формализованный процесс только помешает. Для стартапа главное — гибкость. Потому лучше вместо поиска идеального процесса для немотивированных людей, искать инициативных. И мотивировать их.
Точно отвечу на это:

— Как защищается код от копирования и выноса? И нужно ли вообще переживать по этому поводу?
Если стартап строится на суперсложном алгоритме, код выносить не надо — достаточно «вынести» основу, алгоритм. Как такому помешать?
Если стартап строится на инновационной идее, код выносить не надо — достаточно «вынести» идею.
Кароч, если вы не можете стирать память, это бесполезно.
А если весь стартап базируется на том, что никому в голову не придет некая идея, то стартап скорее всего не разовьется.

Судя по глупейшим вопросам, которые мог задать ТОЛЬКО теоретик, стартапа у тебя нет и не предвидится ближайшие лет 99. Тебя нужно просто чтобы кто-то за тебя про это написал, чтобы стартаперам было интересно.

Приведу простую аналогию — вспомни, что ты знал про секс в детском возрасте, и сравни с тем как на самом деле. Вот и стартап так же.

Прикинься студентом Стэнфорда и возьми себе на почитать.

На поставленные Вами вполне правильные вопросы невозможно ответить в рамках этого форума. Просто есть такая наука — «Управление проектами по разработке ПО» называется. Наука это или нет — можно относиться по-разному, но тем не менее, это сконцентрированные рецепты и шаблоны, говорящие что МОЖНО сделать, чтобы ПОВЫСИТЬ ВЕРОЯТНОСТЬ успешного выполнения проекта (всего-лишь, никаких рецептов о «самом правильном» методе, и накаких стопроцентных гарантий). Так вот, эта наука, которую надо изучить, понять, попытаться применить. К роли менеджера проекта — или более обще СТО в фирме-разработчик — люди идут годами. Через шишки, набитые на позициях линейного девелопмента, через попытки TeamLead’ерства, через целенаправленное изучение тех самых «шаблонов» управления.
А Вы хотите тут и за пять минут.
И еще. На любой из Ваших вопросов может быть дан целый веер возможных (и в принципе — правильных) ответов. А выбор конкретного из них — зависит от очень многих факторов. От решаемых задач до выбранной модели цикла разработки, от квалификации привлеченных исполнителей до распределения ролей в команде, от наличия финансовых ресурсов до умения создать рабочее настроение в коллективе, и т.д....
В общем, Ваш вопрос звучит примерно так, «надо срочно оперировать больного, подскажите, чем резать и как организовать рабочий процесс в операционной».
Ничего личного, просто совет. Исходя из Ваших вопросов самый правильный ответ будет — наймите СТО или Менеджера Проектов. И доверьтесь ему. Ну, или самостоятельно «оканчивайте медицинский институт».
Удачи Вашему стартапу.

Благодарю за то, что уделили время моим вопросам. В частности будет очень полезно почитать современную литературу по этим вопросам. Если есть еще, пожалуйста, дайте названия или ссылки. Спасибо!

Вы действительно решили вместо развития своего продукта «окончить медицинский институт» заняться изучением проектного менеджмента? У людей на это годы уходят.
Главное — при этом не забыть, какой там Вы стартап собирались организовывать :-)
А про литературу — недавно уже выкладывал, вот в этой теме.
dou.ua/...c/12488/#636837
Самые основы так сказать. Теория, которую неплохо и практикой дополнить.
Впрочем — если что — пишите в личку, может чем помогу.

Что нужно чтобы сформировать отдел?

Всем привет!
Руководство передо мною поставило задачу сформировать отдел, способный разработать и поддерживать приложение для android и iphone, а также web-site для нашей компании по продаже и аренде недвижимости. Пользоваться софтом от Terrasoft не хотят. Выделили финансирование. Поставили задачу собрать людей. Опыта в деле программной разработки нет (минимальный). Прошу помощи, с чего начать? Что мне понадобится? Как вообще функционируют подобные отделы?

Рынок на котором работает компания — Чехия. Отдел разработки будет в Киеве.

Например, вам доверили отдел, с чего вы начнете? Как вы организуете работу? Какой софт вам понадобится? Какое оборудование будете закупать? Какой офис будете снимать? Бюджет на год $200 тыс.

Заранее благодарю за ваши ответы!

«Благодарю» за полноценный пошаговый бизнес-план это даже не смешная, а крайне неприличная цена.

Бюджет на год $200 тыс.
Купите много хорошего сыра и туалетной бумаги.

50-80 тис. на саму аренду офіса та всякі організаційні витрати піде.
6 найманих працівників це ще 120 — 200 тис.
З таким бюджетом напевно єдиний варіант це фрілансери.

80k$ * 25грн/$ = 2 000 000 грн на аренду офиса? Вы с ума сошли?

Хорошие офисы сейчас сдают по 100-150-200грн/м.кв/мес, на компашку 6 человек хватит 50 кв.м., т.е. это максимум 10 000 грн/мес или 120 000 грн/год (4.8k$ вместо 80k$).

А можно сэконосить и снять офис во Львове, думаю там будет дешевле чем в Киеве

Купите книжку ДеМарко. «Deadline. Роман об управлении проектами.» Он там именно этот кейс и рассматривает: «Вдруг поручили возглавить фирму по разработке ПО».
Впрочем, герой книги все-таки имел опыт в разработке и с вопроса «Как вообще функционируют подобные отделы?» не начинал. Так что Вам будет еще труднее. Мужайтесь.
Но самое правильное — пойти тем-же путем, что я посоветовал ТС — «наймите нормального ПМ и поручите эту задачу ему».

Начните с найма тимлида. А он уже и подберет команду, снимит офис,...
А вы будете исполнять роль менеджера продукта и представителя заказчика.

Как мне кажется, в описанном кейсе главной ошибкой было бы собрать зоопарк из технологий, например делать сайт на PHP, мобильные приложения на Java и Objective C соответственно. Идеально было выбрать одну технологию, тот же .NET к примеру, и сайт разрабатывать на ASP.NET а мобильные приложения на Xamarin. В этом случае можно нанять тимлида с опытом работы в крупной конторе с хорошей культурой менеджмента.

Этот тимлид строит процессы в компании: VCS, Continuous Integration, инструменты для Code Review, багтрекер, dev и prod энвы, определяется с архитектурой и стандартами написания кода, скрамом и т.д.

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

Попутно смотрим, в каких программах для стартапов типа BizSpark можно поучаствовать, чтобы получить максимум софта и плюшек нашару. Тот же Atlassian предлагает свои продукты для мелких команд по смешным ценам, так что смело берем JIRA, Crucible, Confluence, Bamboo, репозиторий на Bitbucket.

С настроенной инфраструктурой, процессами, формализованным ТЗ начинаем набирать разработчиков, причем чем лучше будет проработан процесс, тем ниже требования к опыту и квалификации. В рамках указанного бюджета можно нанять синьора и нескольких джунов. Кстати, на одном из проектов мы джунов набирали давая всем подряд довольно объемное тестовое задание, на уровне курсовой работы 3-4 курса в виде максимально упрощенного подобия нашего проекта с теми же технологиями. После выполнения человек приходил на собеседование, где с ним общались по его коду, и если все было нормально, то делали оффер. Таким образом получилось нанять очень толковых ребят, которых лидеры рынка забраковали из-за отсутствия опыта.

А вообще, вместо хождения по граблям и изобретения велосипедов, лучше всего нанять на первое время хорошего PM в качестве консультанта.

Принципи управління великими та маленькими компаніями різні. Що необхідно робити в великій, для маленької компанії може бути не тільки зайвим, але й шкідливим.

Зависит не от размеров компании, а от сложности и длительности проектов. Если фирма занимается клепанием сайтов с максимальной ресурсоемкостью до человеко-месяца каждый, то там да, все процессы сводятся к «чик-чик и в продакшн». Хотя даже в этом случае от системы контроля версий отказываться опрометчиво.
Ну а если есть svn или git репозиторий, неплохо бы каждый коммит связывать с таской, в рамкой которой он сделан, чтобы время считать, QA сообщить, что работа закончена, значит нужна JIRA.
Если код покрыт юнит-тестами, то их нужно где-то запускать, и если что-то упало, то на прод не деплоить, значит нужен Continuous Integration сервер (Jenkins, TeamCity, Bamboo, whatever).
Если над кодом работает больше одного человека, то нужно проводить код ревью, со временем становится понятно, что если ревью не привязаны к таске или к коммиту, а пишутся в скайп, к примеру, то на них забивают. Значит нужен софт для код ревью (Crucible, Code Collaborator и т.д.)
Когда команда работает над проектами, объем общих знаний и практических навыков увеличивается, и его важно сохранять в письменном виде, чтобы облегчить онбоардинг новых членов команды и уменьшить риски от ухода старых. Получаем необходимость ведения документации в Wiki или Confluence.

То что я здесь описал, это в наше время необходимость для команды из 3+ разработчиков с 1+ QA и проектами длительностью больше месяца. Можно ли считать такую компанию крупной? А ведь успешные крупные фирмы состоят из таких вот команд, «по-разному скомбинированных и организованных» Все как у классиков (http://khpi-iip.mipk.kharkiv.edu/library/case/buch/ch01.html)

Ну и пример хотелось бы увидеть, что для крупной успешной компании, разрабатывающей софт, это ок, а для маленькой — лишнее и вредное.

Те, що ви описали, майже не стосується до управління. Це адміністративно-організаційні моменти. Особливо звертаю увагу на дуже розповсюджену проблему, коли спочатку обираються інструменти, а потім вже процес пристосовується до них. Правильно робити навпаки — спочатку напрацювати методологію та процеси, потім вже обирати інструменти, які в найкращий спосіб підходять до них.

Отже, приклади зайвих речей з точки зору управління мілкими компаніями.
1. Надлишкове ускладнення організаційної структури. Введення тих позицій, які суттєво збільшують витрати не вирішуючи жодних проблем. Ефективність малих компаній в гнучкій структурі.
2. Ускладнення процесу виробництва або використання процесу великих компаній. Це знову ж таки, призводить до збільшення витрат. Процес виробництва повинен бути направлений на мінімізацію витрат. Наприклад, реорганізація процесу виробництва таким чином, щоб тестувальники були не потрібні на початковому етапі. Це можна досягти через обрання правильної методології розробки.
3. Не використовувати ресурси неналежним чином. Наприклад, не потрібно набирати в команду розробників, які мають низький професійний рівень. Це дозволить мінімізувати витрати на підтримку та рефакторинг коду.
4. Контролювати процес тільки тоді, коли в цьому є потреба. Взаємний контроль в маленькій команді дозволяє не витрачати кошт на зайвий «обслуговчий персонал».
5. Обирання гнучких технологій розробки замість класичних. Тут, я думаю, все зрозуміло.

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

1. Если позиция не приносит пользы, то ее держат только в пост-советских динозаврах, но мы же сейчас о софтверных фирмах? Наличие таких позиций говорит о плохом менеджменте, только и всего.
2. Тестеры нужны с самого начала, особенно если нет аналитиков, и тестить творения девов они должны с первых строчек, ведь мы же помним, что чем раньше ошибка найдена, тем проще и дешевле ее исправить. Чтобы говорить об уменьшении затрат надо сперва посчитать, во сколько нам обойдется каждая prod issue.
3. Так лидеры рынка джунов как раз очень туго набирают. Мелкие фирмы тут могут проявить гибкость и недорого нанять хороших девелоперов (как в моем примере с тестовым заданием в комменте выше)
4. В любом случае даже в маленькой команде будут роли ПМ и тим/тех-лида, иначе бардак. С той или иной эффективностью их могут выполнять и обычные разработчики.
5. С трудом представляю себе waterfall в современных реалиях, везде применяется agile в той или иной форме, главное до маразма не доводить.

1. Зазвичай, в штат набирають людей за паттернами, а не за необхідністю.
2. Тестери потрібні тільки тоді, коли в цьому є необхідність. Та ж методологія екстремального програмування не зовсім передбачає тестерів в процесі, тому що розробка через тестування ведеться. Формалізацію технічних вимог теж можна робити або через ітераційну розробку, або із залученням аналітика.
3. Не всі не завжди. Джун в маленькій компанії більше шкодить, ніж приносить прибуток.
4. Ролі може й будуть, але вони будуть сумісні, а не основні
5. Тоді ви не розробляли проекти із високими вимогами до безпеки. Або аппаратно-програмні комплекси. Там процес розробки майже другорядний.

Підписатись на коментарі