Открыть список
Как стать автором
Обновить

Комментарии 126

НЛО прилетело и опубликовало эту надпись здесь
Это и имеется ввиду :-) Спасибо, сейчас поправлю чтобы было понятнее.
У всех почта должна проверятся с интервалом 1 минута (впрочем, если вы сторонник невмешательства в работу, можно всю срочную коммуникацию перенести в IM, и установить интервал проверки 30-60 минут).

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

Вы должны просматривать то что они закомитили, и спрашивать прямо если нужно: «Ты действительно потратил 8 часов на эти вот 10 строчек?»

А какая разница, сколько я потретил времени на 10 строчек, если я получаю деньги за результат, а не за потраченное время? 10 строчек на каком-нибудь хаскеле можно рожать и больше 8 часов.

Вообще говоря, есть такие понятия, как дисциплина и ответственность. И дисциплинированных, ответственных сотрудников такой тотальный контроль будет мягко говоря нервировать.
Если у человека задачи длинные и не требующие кооперации — то можно и без IM и без почты конечно (но это редкость).
Я разве говорю тотальный контроль? Если прогеры чувствуют что они делают что угодно, и результат один, все идет в разнос.
В статье написано, что строчки бывают разные. Бывают строки которые стоят 8 часов, бывают которые не стоят и 10 минут.
Имхо, постоянный онлайн нужен только тимлиду, а программистам фиксированный по времени окна. У меня на рабочей машине вообще интернета нет, хожу за ним в другую комнату. Зато не отвлекает и нет соблазна слазить куда то просто так.
В некоторых случаях оплата бывает не только за результат, а почасовая. Соответственно вопрос о актуальности 10 строчек за 8 часов вполне может быть очевиден.

И про дисциплину есть очень четкая фраза «скорость стада равна скорости самого слабого в стаде».
Точно, надо в шапке дописать, что оплата почасовая :-) Понятно что если за результат — то не важно когда кто что делает :-)
Кстати, повременка тоже разная бывает. Например, я долго работал, когда учитывалось общее количество часов в неделю. Т.е. в течении недели ты можешь разбросать время как тебе угодно. Друг работал при учете часов в день, т.е. ты тоже обязываешься работать не менее N-го количества, но без «тотального контроля». Конечно, бывали моменты, когда «нужно вчера» и колбасишь всю ночь.
Это к тому, что для распределенной команды в разных часовых поясах можно предлагать удобный для всей команды режим работы, отчетности и оплаты.
Про стадо — это как-то не эстетично :) Лучше так: команда сильна на столько, на сколько силен самый слабый в ней. Если бы я про стадо сказал своим подчиненным, думаю мой авторитет бы упал весьма ощутимо :)
Политики своё стадо вон называют политкорректно — электорат, надо нам тоже что-то придумать )
Никого не хотел обидеть и перед отправкой поста некоторое время стоял перед выбором — соблюсти ли историческую верность фразы или же пытаться перефразировать, ведь «команда сильна на столько, на сколько силен самый слабый в ней» не совсем верна т.к. слабого в этом случае скорее просто задавят и вытеснят, а вот если один не дисциплинированный подает другим пример — это действительно может заразить даже самых стойких.

Про подчиненных вы правы, такого конечно же говорить нельзя :)
скорость стада равна скорости самого слабого в стаде


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

А недостаток контроля даже самых ответственных расхолаживает.
а зачем отчеты, если время и задачи есть в трекере?
В этих багтрекерах время не отмечается.
Вариант с таймтрекером пробовали, с письмом больше ответственности (т.к. его надо отправлять до определенного времени, а таймтрекер — на него часто забивают).
проще поставить fogbuz или jira
для jira существует куча плагинов для оценки прогресса и построения красивых графиков по задачам

вся отчетность нужна менеджеру, а отчеты от программеров, это перевешивание работы с себя на других

Метрики не панацея :-)
Тут ведь нужны не графики, а личное понимание сотрудника, что если буду мало работать — будет сложно писать письмо вечером :-)
По письмо также видно когда оно было отправлено. Самодисциплина тренируется :-)
А можете посоветовать что-то из плагинов для Jira для оценки прогресса и графиков по задачам? Есть какие-то, которые помогают планировать работу и считать сроки?
у нас используют таймтрекер. Выработалось правило: до 12ти часов дня нужно иметь полностью заполненные логи за вчера. Нарушителям не платят потраченные часы. Вот уже спустя год «небыло ни единого разрыва». Нужно просто преподнести до сотрудников это как аксиому.
Сначала были недовольства. Потом — устаканилось.
В команде последнего проекта, где я участвовал (человек 12) всех предупреждали о необходимости писать ежедневные отчёты, и не раз. Не помогало. На репрессии люди естественным образом обижаются и уходят, а отчёты писать тогда мало кто начал.

Про себя: Поначалу я писал. На понятную менеджеру формулировку тратится дофига времени и сил. При том, что менеджер хороший и в технических знаниях даст мне фору много раз подряд, просто естественным образом не в теме всех деталей моих задач, которые знаю я. Я не стал игнорировать отчёты, просто объяснил по-человечески, что мне тяжело тратить кучу времени на вербальную формулировку своих действий — ведь порой исправить баг быстрее, чем описать его комментарием коммита. Так в коммите понимающему человеку виден контекст, где были произведены изменения, что в отчёте пришлось бы описывать отдельно. К тому же между задачами часто переключаешься, отвлекаешься на сопутствующие проблемы и проблемы других разработчиков, в итоге тяжело понять, сколько именно на что потратил.

У меня отчёт сейчас: количество потраченного времени всего и на какой род деятельности я его потратил в основном — правка багов, совместная работа, чтение документации или работа по тикетам.

Подгонка раздутием количества часов не интересна по причине отсутствия строгого контроля за их суммарным количеством. Хотя на самом деле следствие, видимо, обратное.

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

Если шефа интересуют подробности того, что я делаю или делал сегодня и он не может понять это по логам VCS и статусу тикетов — он спрашивает, в этот же день.

Итого:
Ежедневные отчёты с расписанием задач — страшное зло.
Менеджер обязан уметь читать логи VCS и статусы изменения тикетов.
Исследование деталей работ можно производить при подозрении на неудовлетворительную производительность или из технического любопытства, но не ежедневно.
«при желании можно и зайца научить курить» (с)
Это я к тому, что ваше начальство не сильно то и стремилось иметь заполненные логи.

У меня каждое утро начинается с заполнения логов за вчера. И получается, что вчера я не думал о гонке за часами или строгом следовании технического задания. Нужен рефакторинг — я его проводил. А утром сегодня я просто констатировал то, что вчера делал.

Еще не сильно понимаю чем отличается письмо с отчетом от заполнения логов. По-моему это одинаково сложно.

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

Итого: таймтрекер — это отличный компромисс контроля сотрудников и эффективности кода.
Время отмечается даже в последних версиях Мантиса. Но согласен, текстовое описание результатов труда дает куда больше информации, чем перевод issue в статус resolved.
На мой взгляд, Вы забыли упомянуть:

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

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

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

Уже больше двух лет работаем распределенно (заказчик, лид и тестировщик в одном городе, разработчики в нескольких других) и используем для организации и поддержки процесса систему DEVPROM. Лучшего решения нет.
Система интересная конечно, но проприетарная, 350 уе на человека, при том что нет англоязычного интерфейса и оплаты в $ по кредитке(во крайней мере на первый взгляд)… Естественно хостинг на вашем сервере для серьёзного проекта не подойдет.
Цель проприетарности в стремлении идеологической целостности :) Однако, в будущем все может измениться.

Англоязычный интерфейс есть.

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

Скоро будем проводить бета-тестирование 1-го релиза, предполагаются бесплатные раздачи.
извиняюсь, может быть не совсем понял то о чем вы пишите, но DEVPROM, как я понял, это аналог Basecamp?
если да, то каковы его преимущества перед бэйскэмпом?
детаельное описание выслал Вам лично, поскольку читатели не любят ссылок :)

в кратце, basecamp — это инструмент управления задачами, можно квалифицировать его как task manager, и подходит под любую групповую деятельность.

devprom — это существенное большее, и главное, заточенное под процесс разработки ПО, то есть обладает существенно большими возможностями и потенциалом для команд разработчиков ПО.
опять вы со своим devpromом… Вас же уже не раз минусовали за вашу рекламу…
Думаю достаточно любого тимтрекера, и время по задачам выставлять в нем, как и все вопросы по проекту.
Осталось найти заказчика :)
Таймтрекер не так сильно стимулирует дисциплину :-) Не станет же тим лид в час X бежать проверять кто заполнил а кто нет? С письмами сразу ясно кто и когда :-)
Во-первых там может быть настроена рассылка на любое событие.
Во-вторых (в конкретно том, что я использую) есть система статистики в часах за день, месяц, год.
В-третьих при правильной мотивации и нормальном руководителе нет необходимости применения драконовских мер. А система учета времени важна в большей мере для планирования последующих работ и планов загрузки.

Поэтому всегда ясно «кто и когда». Бежать и проверять в час Х ничего не нужно. Это делается по итогам месяца, либо при дедлайнах.
Сам тим лидер и главное у нас в команде это Дружба и Доверие, условие самое простое, у всех включен IM и устоновлен rAdmin.
1. Проснулись, узнали как у кого дела, сказали дружно начали.
2. Не много проманиторил для клиента, если друг сказал что работает а на манеторе redtube.com то сообщение в IM и он вернулся к работе.
Вообще хочу сказать что кроме взаимо доверия и Мониторинга, более не чего не надо.
На счет отчетов, так заказчик сам маниторит либа снимки смотрит, к концу дня по желанию общается с персоналом.
Если сотрудник отстает по графику, а на экране redtube.com то пожалуй стоит искать ему замену, как можно скорее :-)
Лично я считаю что rAdmin это перебор, мы не в Китае :-)
Ну не знаю у нас многим(4) нравится работать под радмином, желания отвлечься много, а так он устоновлен но не у всех включен, многие сами просят приконектится дабы проследить за выполнением работы.
Глянуть что сделано за день в svn — 2-5 минут на человека, а пасти всех по rAdmin — это жесть :-)
Безусловно иногда совместная работа это хорошо, но без причины тратить дорогое время тим лида не стоит :-)
Извеняюсь но СВН это тормоза даже с AutoSVN, у нас ни единая душа на него не отвлекается, все занимаются воим делом, изредко сообщая над чем именно сейчас будут работать.
СВН больше подходит для заказчика который тупо все время обновляет папку на локалки просматривая новые файлы.
Не знаю о чем вы, сколько работаю с svn — все отлично и очень быстро.
Я к тому что без него работается еще быстрее, а так отвлекается как вы писали минуты на 2 на 5 + потерял настрой… Вроде мелочи, а раздражат многих, мы свн только в качестве проверки обновлений предлагаем.
На свн отвлекаться придется только раз в день
да да — а потом весело искать почему вдруг фича перестала работать — когда нет нормальных атомарных к оммитов с описанием что было сделано. Удачи вам в вашем нелегком деле создавания себе лишних проблем
А вы вообще систему контроля версий используете при разработке?
Цитирую отсюда: https://codingvault.org/forum/viewtopic.php?f=4&t=8&p=11

Итак, в каких ситуациях помогает (или даже спасает) использование VCS:

1. Сохранение истории кода — в любой момент времени мы можем вернуться к любому зафиксированному состоянию проекта. Машина времени — это не миф!
2. Синхронизация кода — при участии в проекте более одного человека система позволяет безболезненно производить слияние разных версий исходных текстов.
3. Сохранность кода — при использовании VCS исходный код лежит на рабочих машинах всех разработчиков + на сервере. В такой ситуации потерять код довольно сложно.
— От себя:
4. Если ломается функционал, который ранее работал, меня интересует, когда и почему он сломался. Я пишу тест на этот случай и перебором тестирую все версии от последней до момента, когда тест пройден. А вас интересует, откуда появляются баги в старом функционале? Как решаете?
5. Комментарии в CSV хорошо подходят вместо отчёта.

Если SVN — тормоза, ну попробуйте тогда git или mercurial, что ли.
В радмине не вижу вообще не чего похожего на китай.
«Дружба и Доверие» и при этом обязательный шаринг рабочего стола?!
когда я знаю что за мной могут наблюдать у меня пропадает желание работать.
Когда я знаю что мне доверяют решить задачу так как я считаю правильным и тогда когда мне удобней ( с известными оговорками ) — я чувствую вдохновление и работаю спокойно и эффективно. И если мне нужно почаса на то чтобы прийти в себя и полазить в сети — это мое дело, я сам отработаю это когда вернусь в нормальное состояние.
А как быть, если у разработчика стоит Linux? Насколько я знаю, под эту ОС Radmin'а как бы нет. Да и наличие второго компьютера или ноутбука никто проверить не сможет. Redtube.com вполне и на ноуте можно посмотреть :)
По моему опыту удаленной разработки есть пара дополнений:
1. обязательно нужно использовать общий чат в Скайпе в котором общается вся команда.
2. нужно определить «общее» время, когда все участники в онлайне. Т.е. жестко установить: «с 19.00 — 20.00 (мск) всем быть в скайпе!»

1-е только по необходимости. Постоянно отвлекать всех нет смысла.
2-е — указано.
С 19 до 20 нужно пить пиво, а не сидеть в скайпе.
А зачем заказчику общаться со всеми членами команды? мне кажется он должен иметь связь только с тимлидом
Иногда специалисту легче обьяснить на пальцах, чем тимлидеру на словах.
Я думаю тимлид должен тоже быть специалистом, к тому же заказчик не всегда очень понимает в ИТ, поэтому надо еще уметь объяснять. Плюс манера общения специалиста может оскорбить заказчика, после чего он просто не будет с работать с этой командой больше.
В общем я думаю что в любом случае связь должна идти через тимлида, даже пускай удаленный программист сам сформулирует тимлиду ответ на вопрос заказчика или то что он хочет сказать, а он уже потом передаст это заказчику.
Это зависит от ситуации. В моей ситуации общение напрямую допустимо, и все члены команды достаточно адекватны для прямого общения. Я допускаю что иногда лучше все делать через прокси :-)
согласен, ситуации бывают разные)
Заказчики бывают разные ) Есть такие которые могут что подсказать напрямую. Есть технически-продвинутые заказчики :-)
Ну не надо забывать, что если заказчик заграничный, а специалист наш, родной, то может возникнуть недопонимание в следствие банального языкового барьера. Далеко не все могу свободно общаться на английском. Могут просто неправильно понять друг друга. :)
Более того, часто это даже вредит производству. Не всякий программер любит/умеет общаться с заказчиком. И в таких случаях есть риск не получить решения проблемы, а еще и усугубить моральную обстановку. Заказчик не понял, программер не смог объяснить, в итоге все не довольны. Или, не дай Бог, заказчик/программист поняли друг друга неверно, ведь все заказчики так любят давать задания программисту лично и на словах. Поэтому, я бы советовал избегать прямых контактов. Общение с заказчиком — прямая обязанность руководителя группы.
Все правильно, заказчика ни в коем случае нельзя подпускать к разработчику, ибо его нежный мозг может испортиться от чуждого разуму потока сознания. На каждое задание — ТЗ, понятное программисту.
А не подскажете, каким образом собираются (и расширяются) такие команды, через фрилансовые сайты?
В моём случае — сначала находится тим-лидер(через цепочку знакомых), потом он на разных сайтах (фрилансерских, обычных по поиску работы) он находит нужных люди (но и знакомых тоже может :-) ).
Простите за грубость но это уже гавноменеджмент! Я про то что находится человек который говорит что все умеет, а сам ищет других людей остовляя себе весомый процент.
Вы ничего не поняли, и метаете кал :-)
В оффшорных командах с почасовой оплатой оплата ведется по каждому человеку отдельно.
Даже если тим-лид и оставляет себе часть, в этом его трудно упрекнуть, так работает весь оффшор (а крупные компании вообще себе оставляют иногда до 70-80%). Я так не делаю. У меня своя ставка, у подчиненных — своя.
Мой Колледж обращался к такой фирме, как же они были удивлены когда пришли в офис требовать что же случилось а менеджер, кусал ногти и отписывался прогеру кидале, а второй программист оказался 13 летним мальчишкой который на вопрос «сделать сможешь?» ответил, «я еще не знаю как!»
Я все это к тому что большинство подобных менеджеров не могут гарантировать исполнения работы от «СВОИХ» программистов, так как в большинстве случаев их даже не знают.
По мне Тим Лидер это Лидер и он должен быть лидером и чтобы таковым остоватся он должен знать всех тех кто позади него, только тогда он будет лидером когда за ним пойдут, а не когда ему дали по обещали денег 100000 он 50000 оставил себе а на оставшиеся 5000 пошёл искать людей на фрилансе который сделают то что надо за данную сумму.
И берёт на себя тяжесть общения с невменяемым заказчиком?
И берёт на себя все риски?
И платит деньги вовремя и быстро, независимо от графика рассчёта заказчика?
И берёт на себя или перераспределяет задачи, которые я не могу выполнить в силу недостаточной квалификации?

В итоге — я знаю python, django и умею создавать сложные серверные приложения, я не хочу заниматься вёрсткой, дизайном, удоством интерфейса, контентом, переводом и прочими вещами, которые мне неинтересны. Строю архитектуру, пишу код, и на полученные деньги рассчитываюсь с кредитом за купленную квартиру. Сплю я спокойно, ведь все описанные выше проблемы — решает шеф.

Почему бы не взглянуть на это с такой сторны?
В основном.
Удаленная работа и почасовая оплата — как-то не вяжется.
Уже 4 года у меня все вяжеться. Протирание штанов в офисе с почасовой оплатой тоже не вяжеться :-)
Я уже больше год работаю удаленно, каждый день, по графику (программер я), но почасовую оплату никак не представляю в такой работе. Кто посчитает эти часы? И как?

P.S. вяжется! вяжется! вяжется!
На основе ваших ежедневных отчетов. Тим лидер видит кто сколько делает.
Точно так же как и при работе в офисе — вроде у всех 8 часов, но все равно надо смотреть кто сколько делает.
А если я начну работать на износ по 14-16 часов, не расплатитесь же :)
Просто есть печальный опыт с почасовой оплатой (в офисе, правда).
Если у проекта рекламный бюджет 2млн$, то уж с вами как-нибуть расплатяться :-)
Если у проекта такой рекламный бюджет, зачем нанимают удаленную команду, не пойми где и что? :)
Не всегда был такой бюджет :-) И американцы тоже ленивые бывают )
Пункт про ежедневные отчеты — мне не нравится, это очень некомфортно и обычно после раб. дня сил нормально писать, что сделал желания/сил нет. К тому же некоторые с детства плохо умеют складывать слова в предложения)) и писать связный текст.

Ну и rAdmin упомянутый где-то в комментах — жесть.
Чиркануть пару строчек ИМХО не трудно :-) Не нужно же писать поэму :-)
А rAdmin — это еще не самое страшное ) Была одна компания, там еще веб-камеры надо было иметь :-)
Звучит прямо как из отрывки книги «Ужасы фриланса»))
Работали и на удаленной основе и на on-site с людьми, остановились на on-site, все-таки психологические моменты нельзя списывать со счетов, технически работать удаленно уже давно не проблема.
самое главное в этом – адекватные исполнители. остальное опционально.

а уж если в процессе работы возникает желание пользовать radmin, то нужно сразу разбегаться друг от друга.
ну почему же вы так радмин ненавидите, приведу пример полезности.
В падлу что то заливать кудато, попросил включить радмин, приконектелись тот показал что оно работает и выглядит так, выключил радмин.
Этот пример есть в тексте (с примером YuuGuu), есть масса софта для добровольного шаринга :-)
Добровольный шаринг для решения проблем безусловно удобен.
ненавижу? да с какого....?? нормальный, полезный инструмент.
однако когда его начинают использовать для контроля рабочего времени удаленных сотрудников… перспективы у такой команды смутные.
Ненависть не к радмину, а ощущению, что за спиной надсмотрщик.
На данный момент меня больше привлекает работа в обществе/команде.
Автор признай, твои шакалы?! минусы ставят везде где только могут, даже в самых безобидных и правельных сообщениях которые минутой ранее имели +2, чего испугался что ли меня? Я просто правду говорю, а ты за топ держишся, да еще о ТимЛидирстве пытаешься говорить, фу как не красиво.

ps/ обидно только одно, временное ограничение.
не думаю, что это автор
адекватная аргументация редко перекликается с минусованием неугодных)
не редко
Нет, это не я. И «шакалов» у меня тут нет, я тут вообще 3-ий день :-)
Вы бы подумали над формулировкой сообщений и правописанием, а потом минусам удивлялись. Ваши мысли очень тяжело читать, и даже при всей их гипотетической правильности они просто могуть быть не прочитаны до конца )
да ты просто далбаеб :)
не нравитесь Вы мне, со своими высказываниями про radmin и про то, что система контроля версий зло ненужное :)
сорри всем, что не сдержался…
Зря вы так, может начаться травля :-)
А у меня вопрос касательно где и как можно найти предложения о распределенной работе?
хабр и мойКруг
еще фриланс.ру, но там слишком много шелухи
Выскажусь с колокольни простого разработчика.
Система контроля версий — благо с какой стороны не посмотри.
Багтрекер в комплекте с wiki — сильнейшая подпорка для памяти, сложно что-то оговоренное упустить.
Ежедневные отчёты с почасовой раскладкой — скорее зло. Обосную — зловредный баг ищется 4 часа, правится 1 строка. Возникает вопрос — зачем держать такого разгильдяя? Не будешь же указывать в отчёте мегабайты переворошённых дампов и десятки экспериментов по локализации вредной ошибки.
Гораздо лучше ежедневная раскладка заданий — минимум, норма и максимум.
Отчеты же читает тоже программист, он все понимает, что дебаг бывает неделями, что фиксится обычно одним символом :-)
Вполне нормально указывать в отчете «мегабайты переворошённых дампов и десятки экспериментов по локализации вредной ошибки». Более того обязательно указывать сколько времени потратил на чтение документации, связанных статей, просмотров примеров и т.п., т.к. это реальная работа. А если адекватный руководитель группы, то не грех указывать и время на самообучение и «интернет».
Что только не придумают чтоб не пользоватся BaseCamp.
А статья по делу, несоблюдение таких простых правил ведет к снижению результативности в несколько раз.
BaseCamp платный.
Да. Но он стоит тех денег, что за него просят. Не все так шиколадно, как пишут, но очень качественно.
А бесплатных аналогов сравнимых нет?
Я уже нашел для себя :-) Redmine — не вижу чем Basecamp лучше. Деплоить только с непривычки сложно, напишу статью о том как я 8 часов ставил на свой хостинг Redmine :-)
Очень удобен для коммуникации команды IRC. Можно создавать каналы связанные с каждым проектом. В отличии от скайп отвлекает гораздо меньше.
тогда уже джаббер конференции на корпоративном сервере… можно и настроить хранение истории — совсем в таком деле не повредит.
Irc сервер работает через proxy, который логирует информацию и отдает ее даже если ты оказался в оффлайн на какое-то время.
IRC для командной работы намного удобней пейджеров.
Там проблемы с отправкой кусков кода — больших многострочных сообщений.
кусок кода куда приятнее видеть подсвеченным.
pastemonkey или bin.cakephp.org
Не всем, но, в целом, да — большой проблемы нет.
Мысль: а ещё иногда google docs можно использовать для совместного редактирования на ходу.
Спасибо за статью. Ввиду того, что скоро придется окунуться во все это с головой читал с интересом и удовольствием.

Идея с шарингом десктопа очень понравилось. Удивительно простая, но насколько полезная! :) Вики, баг/таск-трекер и SVN — разумеется да.

Что касается SVN то есть вопрос — что используете вы? Какое-то решение на собственном сервере или же свободные площадки? Если можно, то прошу описать поподробнее :)
У нас раньше был свой железный сервер, теперь хостимся у springloops.com
Дешево и сердито, проблем со скоростью нет.
Найти бы где-нибудь *реально* удаленный проект, было бы очень и очень здорово.
Наиболее интересна JEE разработка, потому что в ней наиболее сильные скиллы. Есть неплохой опыт java + swing.

Если не java, то есть опыт в разработке на python и ruby (не rails). Ещё есть небольшой опыт в c++/qt для девайсов, то есть не для pc, а для некой железки под бизибоксом.

У вас есть предложения? Если да, то давайте пообщаемся по хабрапочте например.
Угу, помню как лид (немец) чуть не плакал когда общался с двумя китайцами и индусом по скайпу (на тот момент я только наблюдал, т.к. сам выполнял малозначительную работу)
С индусами жесть ) Сам с ними работал :-)
И что с ними было не так? Я сам работал, но хотелось бы услышать чужое мнение/
Английский ужасен, код — хорошо если комменты на английском, первый раз попал код с камментами и именами констант по ихнему. В крупных компаниях особенно мешает первое, второе редкость :-)
Какая схема работы по денежным переводам с заказчиком с программистами?
Спасибо
Официальная работа с трудовой в фирме-посреднике. Получаем на карточку, за вычетом налогов. В фирме появляемся только если надо что-то подписать.
Меня интересовало вам зарубежные клиенты переводят деньги на счет
(как знаю здесь много сложностей возникает), на личную карточку кому-то или электронными деньгами.

Если по трудовой, то тогда получается, что все работающие находятся не так далеко — примерно в одной области, и фактически это не полноценные фрилансеры, а официально работающие удаленные сотрудники.
ТАк сверху же написано ) Как и у обычных оффшорных компаний — wire, с которым потом бугалтерия сама разбирается. Речь о фрилансерах не шла, речь шла именно об удаленных сотрудниках в команде которая работает долго.

Ну, у нас страна(Беларусь) как ваша область :-) А те кто подальше — тем тоже wire, но они зарегестрированны как предприниматели.
Скажите, а вот вы пробовали повесить на репозиторий post-commit hook, который искал бы в комментарии к коммиту фразы типа «fixed #номертикета» и автоматически закрывал (или ресолвил, или assignил на тестировщика) тикеты, упомянутые в таком контексте? Например — changeset, ticket.
Боюсь предположить, но в таком случае формирование отчётов можно было бы переложить на сам багтрекер. Как вы считаете?
в trac есть такой плагин
это часть его функционала, если точнее. обработчик этого хука находится в дистрибутиве trac
Спасибо за дельные советы! Вообще, я думаю что подобные отчеты нужно требовать и тим-лиду к офисным работникам, возможно менее строгий, т.к. все находятся в одном помещении. Контроль работников и их мотивация крайне необходимы, убедился самолично.
Сам так работаю. Схема как Вы и описали. А по другому и не получится.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.