Давайте попробуем немного разграничить разные значения слова «стартап», которое сегодня стало своего рода зонтичным термином.
1. Стартап сферический. Это предполагаемый экземпляр абстрактного класса, свойства которого жество заданы в любой уважаемой книжке уважающего себя стартап-гуру. Количество основателей 2-4, возраст 18-25, график работы 24х7, источники финансирования FFF, предметная область — что-то связанное с социальными сетями и мобильностью, лучше всего — клон известного и уважаемого западного проекта, что почти гарантирует будущий выход на IPO, продажу стартапа с потрохами и уход на пенсию в 30-35 лет.
Если кто-нибудь где-нибудь такой увидит — киньте ссылку плз, хочется полюбоваться на такое чудо:)
2. Человек-стартап. В принципе, это не стартап как таковой, с IPO и прочим блекджеком, а просто подход к своей карьере как к бизнес-проекту стартапного типа. Может включать в себя фриланс, первое и дальнейшее ВО, самообучение, работу в Большой Корпорации, основание стартапа сферического и другие подобные фичи. Все это с одной стороны подчиняется единому плану, с другой — следует за рынком. Стартап-карьеру от прочих ее разновидностей отличает изрядная доля непредсказуемости, линейный марш-бросок по трупам до должности начальника — не для человека-стартапа. Он практически никогда не становится руководителем путем повышения по службе, а только в случае найма сотрудников в созданный им же стартап, и то классический менеджерский подход ненавидит, предпочитая более партнерские отношения.
3. Стартап среднестатистический массового пользования. Это проект, реализация которого не требует особых познаний в предметных областях за пределами собственно разработки технической части и бизнес-логики, теоретически понятной даже ребенку. Данные условия означают, что подобный проект может быть начат любым человеком с дипломом ИТ или научившимся программированию/дизайну/и т. п. самостоятельно, возможно — с привлечением человека с дипломом экономиста, юриста или менеджера для написания бизнес-плана и прочих «мелочей», от которых чуть более чем часто может зависеть успех всего проекта. Именно такие проекты бросаются создавать все кому не лень уже не с первого курса, а со школы, и главное здесь понять, не вырождается ли п. 3 в п. 1. Сам по себе факт «доступности» бизнес-идеи любому школьнику к шансу на успех проекта не имеет никакого отношения, существуют тысячи примеров доказавших себя бизнесов, равно как и тысячи обратных примеров.
4. Стартап наукоемкий. Создается человеком, работающим в какой-нибудь лабе над какими-нибудь нетривиальными задачами, нередко — с каким-нибудь нетривиальным дипломом. Фактор школоты исключен, зато возможен фактор советского инженера v2.0, неспособного (или неспособного найти человека, способного) встроить это всё в работающую как следует бизнес-модель. Часто реализовать такую еще сложнее, чем п. 3, т. к. специалист по бизнесу должен разбираться еще и в предметной области, а готовить обладателей тех и других навыков в наших вузах начали совсем недавно и в обществе предпринимательская культура должного уровня тоже не везде еще проникла. Фактически же п. 4 — родоначальник понятия «стартап» вообще.
5. Стартап с претензией на попадание в историю («второй гугл/фейсбук/твиттер и т. п.»). Чуть более чем всегда в историю не попадает, а влипает. Иногда умудряется поднять миллиард-другой и все эти деньги перевести в органическое удобрение. Также нередко пытается клонировать лидера своего рынка и мечтает его потеснить. Предел удачи для него — быть выкупленным этим лидером на корню вместе с командой за $100500,00.
6. Видимость стартапа, создаваемая с целью распила бабла и менее опосредованных видов мошенничества. No comments.
7. Стартап, попадающий в историю и меняющий мир навсегда. Microsoft, Apple, Google, Facebook. Отличается: А. Полным отсутствием правил и алгоритмов успеха, ибо сам эти правила и алгоритмы пишет. Б. Принципиальной новизной явления. Это не экземпляр класса и не класс, а как минимум новое ключевое слово языка, как максимум новая парадигма программирования. Программное обеспечение. Компьютер для ГСМ. Универсальный поиск. Социальная сеть. Возможно, подобный общий термин для определения следующей «бомбы» придумают уже после ее появления. Что такое твиттер, к примеру? Успех также не гарантирован — можно взять идею и превратить ее в удобрение вроде MySpace. Всего лишь не хватило более жесткой структуры данных, которую мог бы заполнить даже шимпанзе, вместо вгоняющей в растерянность гибкости. В целом здесь работает только одно правило — чем более странной и неожиданной кажется идея, чем больше в ее отношении крутят пальцем у виска, чем сильнее она противоречит сложившейся культуре или идет поперек нее — тем больше у нее шансов выстрелить.
Кроме того, могу порекомендовать http://www.hemingwayapp.com/ — поможет держать сложность под контролем. Сложные составные предложения при разбиении на простые дают мгновенный буст к грамотности. Особенно когда калькой с русского языка тянется структура вроде: "Нами разработана высокоинтелектуальная система %SYSTEM_NAME%, которая позволяет %SOMETHING1%, %SOMETHING2% и %SOMETHING3%, делая процесс %PROCESS_NAME% чем-то там эффективнее, а кроме того снижая временные затраты работников %INDUSTRY_NAME%".
я довольно подробно изучаю этот вопрос. Вот список возможных вариантов. Кстати, я продолжаю изучать этот вопрос, кому интересно — могу делиться инфой, по мере ихучения приведенных вариантов. Кому интересно — напишите под этим комментом
Сразу извиняюсь за задержку моих ответов, просто только встал! По поводу Ваших коментариев — я плюсую — кому-то легче, кому-то сложнее. Недавно встретил человека, который проделал очень длинный путь, но в итоге добился своего. Мой личный опыт (а также опыт друзей) — попытка стажировки. Дело в том, что на стажировка дает много плюсов (помимо опыта!). Например, на моих интервью добрых 50 % времени я рассказывал о своих проектах. Ну и, конечно, Ваше резюме выглядит намного впечатляюще. Я, кстати, сейчас говорю не только о загранице. В России Яндекс и СКБ Контур (2 компании, о которых я знаю) проводят стажировки. Задачи на алгоритмы лично мне помогают держать мозги в тонусе. Я продолжаю решать регулярно. Очень рекомендую codeforces.ru и topcoder.com. Порешав может с пару месяцеа регулярно, увидите, что будет прогресс.
У меня в этом плане такой опыт: я в договор обязательно включаю раздел, описывающий условия приемки этапов проекта. В частности:
1. Что может являться поводом неподписания акта выполненных работ. Здесь важно ограничить заказчика рамками технического задания. Чтобы его дополнительные «хотелки», которые он обнаружил во время тестирования, не могли быть основанием для отказа в приёмке.
2. Порядок тестирования и сроки тестирования.
3. «Автоматическую приёмку» акта, если заказчик не предоставил подписанный акт в сроки по договору, и не предоставил мотивированный отказ.
Пока ни одного прокола с этой схемой у меня не было. Единственное, заказчики в таком случае также часто требуют соблюдения дисциплины по сдаче этапов проекта и с нашей стороны. Но это же не должно пугать хороших разработчиков, верно? :)
С Mojolicious (perl framework) не знакомы? Можно гораздо проще сделать на нем, регулярные выражения и внешний wget не потребуется. А еще есть телеграмм бот готовый под ваши нужды, ссылку оставлять не буду, отвечу в личке.
Нет, поверьте сейчас намного лучше того что я прочитал в первый раз. Я могу вам порекомендовать писать в информационном стиле, прогонять текст через Главред и стараться по минимуму писать про свои впечатления, так как именно они будут отдавать дешевой рекламой.
3.5 Если в процессе выполнения работ выясняется неизбежность получения отрицательного результата или нецелесообразность дальнейшего проведения работ, Исполнитель обязан приостановить ее, поставив об этом в известность Заказчика в 3-дневный срок после приостановления работы. В этом случае стороны обязаны в 7-дневный срок рассмотреть вопрос о целесообразности и направлениях продолжения работ.
4.6 В случае немотивированного отказа Заказчика от продолжения разработки интернет-представительства, Исполнитель возвращает Заказчику предоплату за вычетом суммы пропорционально выполненной работе согласно техническому заданию.
Вот пункт 4.6. нас однажды конкретно спас.
Когда сайт уже был готов к запуску и тестировался на сервере. Пришел заказчик и сказал что фирма закрывается, сайт им больше не нужен, акт они подписывать не будут и хотят чтобы мы вернули все 100% предоплаты.
Пришлось ткнуть носом в этот пункт и записать им сайт на диск.
По пункту 3.5. тоже примерчик имеется
Официальное письмо руководителю компании с ссылкой на этот пункт. Отрезвляет истерикующих в нашем офисе менеджеров, которым некая фирма предложила прекрасный откат, но уже после подписания с нами договора и начала работ
Брошу свои десять копеек, из опыта.
1. Статическая типизация.
— CUDA это C/C++ и жесткая типизация, во-первых потому, что разделяемой памяти мало (16 или 48 КБ), начинаешь как в старые времена думать, что массив 16-битных величин лучше чем 32-битный. В старых версиях (до 1.3) double обрабатывается сильно дольше, чем float.
— Приходилось писать плагины для photoshop и Ogre3d — здесь только С… Хотя я бы рассмотрел вариант питона :-)
— Обработка видео в реальном времени — детектирование/распознавание объектов. Нужно обработать HD кадр за 10 мс, пока на PC, а потом скорее всего на ARMe — здесь только C/C++ (причем без всяких там STL и прочих смарт поинтеров)
Java. Для той же задачи, для которой писали плагины для Ogre, нужна была небольшая база из четырех табличек. Пытались на QT(дабы соблюсти идейную чистоту C++) — на Java оказалось сильно проще.
2. Динамическая типизация. Про web писать не буду — К.О. уже все сказал…
— Бизнес логику в учетных и ERP системах пишем на 1С, начинали с 7.1, сейчас 8.2. ИМХО, это лучшая платформа для erp, на практике сравнивали с SAP/R3, Oracle E-Business Suite, Sun Account, Site Line, Axapta…
— Прототипирование математических алгоритмов (тех самых, которые потом переписываются на C/CUDA) пишем в Matlab, и также, имхо, это лучшая система для разработки прототипов математических алгоритмов.
— Простенькие утилитки пишу на perl/python для разных задач разные библиотечки, так wxPython очень нравится для очень быстрого создания GUI, а с ImageMagick удобнее через perl(а может просто привычнее), с другой стороны, некоторые функции работы c изображениями мне нравятся в PIL…
Так что, как говорится, у каждой церкви свой Будда, а для каждого класса задач свой язык.
Полезный обзор! И все же здесь речь не совсем об инструментах мониторинга социальных сетей. Кроме того — социальные сети — часть единой экосистемы под названием «социальные медиа», куда также входят блоги, микроблоги, комментарии в онлайн-сми и даже форумы, которые продолжают успешно сосуществовать с трендовыми социальными сетями (подробнее об этом, например, тут: www.likeni.ru/analytics/sotsialnie-yeti/). Грань между всеми этими «медиа для общения» очень часто размыта — меняется функционал, но не меняется суть.
Инструменты для мониторинга социальных медиа в России очень активно развиваются, более того, в силу специфики Рунета западные инструменты достаточно плохо «ловят» сообщения на наших просторах. Именно поэтому ни один западный инструмент для мониторинга не стал популярным в России (например, Radian6). Зато заточенные под Рунет инструменты очень даже активно развиваются, например такие пионеры мониторинга в России, как BrandSpotter или Youscan. Неплохой обзор есть вот по этой ссылке www.hopesandfears.com/hopesandfears/cloud/cloud/119661-8-sposobov-sledit-za-konkurentami, но он тоже касается разных областей бизнеса.
Семён, подтверждаю. Не хотел давать ссылки, чтобы не сочли за рекламу.
Мы пробовали…. Ух. Целую кучу всего.
Весной 2012 мы работали с redmine, но нам не хватало CRM-функционала.
В мае 2012 мы воспользовались Мегапланом (самым крутым пакетом) — всё, что касается расходов и ЗП было супер, CRM был плюс-минус удобный, трекер задач совершенно неудобный. Именно представление списка — как дерево, так и табличное представление. Ну и цена за систему, которая не удовлетворяла нас на 100% была достаточно большой.
Затем мы перешли на planfix — в целом функционал расходов и счетов был понятный, CRM средненький (даже слабый на тот момент), таск-трекинг был неудобный. И самое главное — он жутко тормозил периодически. И иногда даже падал
Параллельно мы работали во Wrike (и одного клиента до сих пор ведём там) — самый удобный таск-трекер. Но на единую систему для IT-компании к сожалению не тянет.
Следующей системой (примерно сентябрь-октябрь 2012) был www.birdviewprojects.com Им мы пользовались чуть больше месяца. Затем мы окончательно устали, изучили ещё 3-4 системы, смотрели и в сторону saleforce как CRM и на американские системы. В итоге купили плагин CRM, Invoices и вернулись в редмайн. Счастью не было предела) Оказалось, что как таск-трекер он самый-самый, а то, что даёт CRM+Invoices покрывает наши нужды процентов на 70. Аналитика и заплаты остались за бортом, я сам накропал для этого на fuel-php небольшую систему учёта и в общем-то творческий поиск остановился.
Уже очень давненько «свалил», по вашему выражению, хотя и по другим причинам, зарубеж. Что не мешает мне до сих пор считать себя патриотом (страны прошу заметить, а не правящей партии). Но… читая хабр и вообще околоайтишные новости России последних лет, все меньше переживаю по поводу «чего блин уехал» (ностальгия жеж мать ее). Да и причин, чтобы наступить ей (ностальгии) на горло и уже не возвращаться никогда обратно, появляется все больше и больше.
А еще несколько лет назад, оне вроде бы хотели «высококвалифицированных иностранных специалистов» привлекать. Ну-ну. Тут бы свои не разбежались… И ведь, что не день, то новая «радость». И нет бы хотя бы экономически обосновано, ну с выкладками там или оценками и т.д. и т.п. А то как-то все: бабах — сегодня мысль пришла, бабах — завтра приняли на палитбюро. [Блин] и ругаться низя, а то бы…
П.С. Не то чтобы в европах глупых решений не напринимали. Еще как, целыя мемуары понаписать можно. Но то ведь европы, а то Родина — грустно просто и душа болит.
Кстати, мало ли пригодится. Мы используем такой сервис для встраивания техподдержки в приложение www.helpshift.com/, там можно делать и фак и чтобы пользователи из приложения писали. Интеграция довольно простая.
Такие есть и выход в работе с ними — дожимать до конца в стиле "нет ножек нет и мультиков нет инфы нет и помощи, ибо не ясновидящие". Пытаться же наванговать что-то без необходимой информации ведет только к обострению ситуации и демонстрации непрофессионализма со стороны саппорта.
В свое время я сделал для молодняка вот такую схему, которую до сих пор успешно используют на том месте в обучении, насколько я знаю. Да и просто в работе:
Самое важное в использовании этого рабочего алгоритма — это корректно осуществлять поиск инфы своими силами, а если не нашли, правильно и полно оформлять запрос на инфу, максимально доступно и прозрачно и все одним письмом. Потому что если вы запросите только часть информации, то в последующем это выливается в «допрос» и загоняет схему в недопустимый для саппорта цикл ненужной переписки.
В идеале, каждый тикет должен закрываться в 1-2 ответа (сразу анализ на месте и ответ, либо запрос инфы => ответ). Только так, и никак иначе.
Чаты — зло, повторяю. Если человек поймет, что ему отвечают в реал-тайм, то вытянут инфу будет еще сложнее, а вот когда приходит осознание, что между ответами может быть пауза, обычно люди, у которых есть реальная проблема, все же присылают запрошенную инфу в надежде, что это поможет сразу же решить их проблему.
А чат может выглядеть по итогу так:
"- Эй вы, го***ки, у меня платеж не прошел!
— Здравствуйте, дайте нам %%инфа%%
— Идите в зад, у меня бабки пропали, где мое бабло!?
— дайте нам %%информацию%%
— НЕ мои проблемы, вот вам %%часть инфы%%, больше не помню.
— Поищите
— Мне в лом! Вы поддержка или кто?! Вы тут сидите и фразочки строчите вместо того, чтобы решать мою проблему!
— Мы не сможем вам помочь без %%инфы%%.
— Дайте мне ваше начальство сейчас же, вы не хотите работать!"
1. Стартап сферический. Это предполагаемый экземпляр абстрактного класса, свойства которого жество заданы в любой уважаемой книжке уважающего себя стартап-гуру. Количество основателей 2-4, возраст 18-25, график работы 24х7, источники финансирования FFF, предметная область — что-то связанное с социальными сетями и мобильностью, лучше всего — клон известного и уважаемого западного проекта, что почти гарантирует будущий выход на IPO, продажу стартапа с потрохами и уход на пенсию в 30-35 лет.
Если кто-нибудь где-нибудь такой увидит — киньте ссылку плз, хочется полюбоваться на такое чудо:)
2. Человек-стартап. В принципе, это не стартап как таковой, с IPO и прочим блекджеком, а просто подход к своей карьере как к бизнес-проекту стартапного типа. Может включать в себя фриланс, первое и дальнейшее ВО, самообучение, работу в Большой Корпорации, основание стартапа сферического и другие подобные фичи. Все это с одной стороны подчиняется единому плану, с другой — следует за рынком. Стартап-карьеру от прочих ее разновидностей отличает изрядная доля непредсказуемости, линейный марш-бросок по трупам до должности начальника — не для человека-стартапа. Он практически никогда не становится руководителем путем повышения по службе, а только в случае найма сотрудников в созданный им же стартап, и то классический менеджерский подход ненавидит, предпочитая более партнерские отношения.
3. Стартап среднестатистический массового пользования. Это проект, реализация которого не требует особых познаний в предметных областях за пределами собственно разработки технической части и бизнес-логики, теоретически понятной даже ребенку. Данные условия означают, что подобный проект может быть начат любым человеком с дипломом ИТ или научившимся программированию/дизайну/и т. п. самостоятельно, возможно — с привлечением человека с дипломом экономиста, юриста или менеджера для написания бизнес-плана и прочих «мелочей», от которых чуть более чем часто может зависеть успех всего проекта. Именно такие проекты бросаются создавать все кому не лень уже не с первого курса, а со школы, и главное здесь понять, не вырождается ли п. 3 в п. 1. Сам по себе факт «доступности» бизнес-идеи любому школьнику к шансу на успех проекта не имеет никакого отношения, существуют тысячи примеров доказавших себя бизнесов, равно как и тысячи обратных примеров.
4. Стартап наукоемкий. Создается человеком, работающим в какой-нибудь лабе над какими-нибудь нетривиальными задачами, нередко — с каким-нибудь нетривиальным дипломом. Фактор школоты исключен, зато возможен фактор советского инженера v2.0, неспособного (или неспособного найти человека, способного) встроить это всё в работающую как следует бизнес-модель. Часто реализовать такую еще сложнее, чем п. 3, т. к. специалист по бизнесу должен разбираться еще и в предметной области, а готовить обладателей тех и других навыков в наших вузах начали совсем недавно и в обществе предпринимательская культура должного уровня тоже не везде еще проникла. Фактически же п. 4 — родоначальник понятия «стартап» вообще.
5. Стартап с претензией на попадание в историю («второй гугл/фейсбук/твиттер и т. п.»). Чуть более чем всегда в историю не попадает, а влипает. Иногда умудряется поднять миллиард-другой и все эти деньги перевести в органическое удобрение. Также нередко пытается клонировать лидера своего рынка и мечтает его потеснить. Предел удачи для него — быть выкупленным этим лидером на корню вместе с командой за $100500,00.
6. Видимость стартапа, создаваемая с целью распила бабла и менее опосредованных видов мошенничества. No comments.
7. Стартап, попадающий в историю и меняющий мир навсегда. Microsoft, Apple, Google, Facebook. Отличается: А. Полным отсутствием правил и алгоритмов успеха, ибо сам эти правила и алгоритмы пишет. Б. Принципиальной новизной явления. Это не экземпляр класса и не класс, а как минимум новое ключевое слово языка, как максимум новая парадигма программирования. Программное обеспечение. Компьютер для ГСМ. Универсальный поиск. Социальная сеть. Возможно, подобный общий термин для определения следующей «бомбы» придумают уже после ее появления. Что такое твиттер, к примеру? Успех также не гарантирован — можно взять идею и превратить ее в удобрение вроде MySpace. Всего лишь не хватило более жесткой структуры данных, которую мог бы заполнить даже шимпанзе, вместо вгоняющей в растерянность гибкости. В целом здесь работает только одно правило — чем более странной и неожиданной кажется идея, чем больше в ее отношении крутят пальцем у виска, чем сильнее она противоречит сложившейся культуре или идет поперек нее — тем больше у нее шансов выстрелить.
В начале — боль и невозможно. Потом привыкаешь, и оно сильно улучшает письменную речь.
Кроме того, могу порекомендовать http://www.hemingwayapp.com/ — поможет держать сложность под контролем. Сложные составные предложения при разбиении на простые дают мгновенный буст к грамотности. Особенно когда калькой с русского языка тянется структура вроде: "Нами разработана высокоинтелектуальная система %SYSTEM_NAME%, которая позволяет %SOMETHING1%, %SOMETHING2% и %SOMETHING3%, делая процесс %PROCESS_NAME% чем-то там эффективнее, а кроме того снижая временные затраты работников %INDUSTRY_NAME%".
Собственно, список:
Биржи:
www.toptal.com
www.scalablepath.com
crew.co/how-it-works
gun.io
www.guru.com
mycrowd.com
www.freelancer.com/dashboard
authenticjobs.com
jobspresso.co
remoteok.io
Не биржи, но тоже инструменты, с помощью которых можно найти дистанционную работу:
angel.co
github.com
hubstaff.com/jobs
Исключительно для дизайнеров:
99designs.com
www.crowdspring.com
Что-то непонятное (не изучал):
www.mturk.com
microworkers.com
hourlynerd.com
www.cloudfactory.com
coworks.com
jobbatical.com
remote.co
jobs.remotive.io
weworkremotely.com
hired.com
www.airpair.com
www.topcoder.com
hackerlist.net
x-team.com
www.sofmen.com
1. Что может являться поводом неподписания акта выполненных работ. Здесь важно ограничить заказчика рамками технического задания. Чтобы его дополнительные «хотелки», которые он обнаружил во время тестирования, не могли быть основанием для отказа в приёмке.
2. Порядок тестирования и сроки тестирования.
3. «Автоматическую приёмку» акта, если заказчик не предоставил подписанный акт в сроки по договору, и не предоставил мотивированный отказ.
Пока ни одного прокола с этой схемой у меня не было. Единственное, заказчики в таком случае также часто требуют соблюдения дисциплины по сдаче этапов проекта и с нашей стороны. Но это же не должно пугать хороших разработчиков, верно? :)
3.5 Если в процессе выполнения работ выясняется неизбежность получения отрицательного результата или нецелесообразность дальнейшего проведения работ, Исполнитель обязан приостановить ее, поставив об этом в известность Заказчика в 3-дневный срок после приостановления работы. В этом случае стороны обязаны в 7-дневный срок рассмотреть вопрос о целесообразности и направлениях продолжения работ.
4.6 В случае немотивированного отказа Заказчика от продолжения разработки интернет-представительства, Исполнитель возвращает Заказчику предоплату за вычетом суммы пропорционально выполненной работе согласно техническому заданию.
Вот пункт 4.6. нас однажды конкретно спас.
Когда сайт уже был готов к запуску и тестировался на сервере. Пришел заказчик и сказал что фирма закрывается, сайт им больше не нужен, акт они подписывать не будут и хотят чтобы мы вернули все 100% предоплаты.
Пришлось ткнуть носом в этот пункт и записать им сайт на диск.
По пункту 3.5. тоже примерчик имеется
Официальное письмо руководителю компании с ссылкой на этот пункт. Отрезвляет истерикующих в нашем офисе менеджеров, которым некая фирма предложила прекрасный откат, но уже после подписания с нами договора и начала работ
1. Статическая типизация.
— CUDA это C/C++ и жесткая типизация, во-первых потому, что разделяемой памяти мало (16 или 48 КБ), начинаешь как в старые времена думать, что массив 16-битных величин лучше чем 32-битный. В старых версиях (до 1.3) double обрабатывается сильно дольше, чем float.
— Приходилось писать плагины для photoshop и Ogre3d — здесь только С… Хотя я бы рассмотрел вариант питона :-)
— Обработка видео в реальном времени — детектирование/распознавание объектов. Нужно обработать HD кадр за 10 мс, пока на PC, а потом скорее всего на ARMe — здесь только C/C++ (причем без всяких там STL и прочих смарт поинтеров)
Java. Для той же задачи, для которой писали плагины для Ogre, нужна была небольшая база из четырех табличек. Пытались на QT(дабы соблюсти идейную чистоту C++) — на Java оказалось сильно проще.
2. Динамическая типизация. Про web писать не буду — К.О. уже все сказал…
— Бизнес логику в учетных и ERP системах пишем на 1С, начинали с 7.1, сейчас 8.2. ИМХО, это лучшая платформа для erp, на практике сравнивали с SAP/R3, Oracle E-Business Suite, Sun Account, Site Line, Axapta…
— Прототипирование математических алгоритмов (тех самых, которые потом переписываются на C/CUDA) пишем в Matlab, и также, имхо, это лучшая система для разработки прототипов математических алгоритмов.
— Простенькие утилитки пишу на perl/python для разных задач разные библиотечки, так wxPython очень нравится для очень быстрого создания GUI, а с ImageMagick удобнее через perl(а может просто привычнее), с другой стороны, некоторые функции работы c изображениями мне нравятся в PIL…
Так что, как говорится, у каждой церкви свой Будда, а для каждого класса задач свой язык.
Инструменты для мониторинга социальных медиа в России очень активно развиваются, более того, в силу специфики Рунета западные инструменты достаточно плохо «ловят» сообщения на наших просторах. Именно поэтому ни один западный инструмент для мониторинга не стал популярным в России (например, Radian6). Зато заточенные под Рунет инструменты очень даже активно развиваются, например такие пионеры мониторинга в России, как BrandSpotter или Youscan. Неплохой обзор есть вот по этой ссылке www.hopesandfears.com/hopesandfears/cloud/cloud/119661-8-sposobov-sledit-za-konkurentami, но он тоже касается разных областей бизнеса.
Мы пробовали…. Ух. Целую кучу всего.
Весной 2012 мы работали с redmine, но нам не хватало CRM-функционала.
В мае 2012 мы воспользовались Мегапланом (самым крутым пакетом) — всё, что касается расходов и ЗП было супер, CRM был плюс-минус удобный, трекер задач совершенно неудобный. Именно представление списка — как дерево, так и табличное представление. Ну и цена за систему, которая не удовлетворяла нас на 100% была достаточно большой.
Затем мы перешли на planfix — в целом функционал расходов и счетов был понятный, CRM средненький (даже слабый на тот момент), таск-трекинг был неудобный. И самое главное — он жутко тормозил периодически. И иногда даже падал
Параллельно мы работали во Wrike (и одного клиента до сих пор ведём там) — самый удобный таск-трекер. Но на единую систему для IT-компании к сожалению не тянет.
Следующей системой (примерно сентябрь-октябрь 2012) был www.birdviewprojects.com Им мы пользовались чуть больше месяца. Затем мы окончательно устали, изучили ещё 3-4 системы, смотрели и в сторону saleforce как CRM и на американские системы. В итоге купили плагин CRM, Invoices и вернулись в редмайн. Счастью не было предела) Оказалось, что как таск-трекер он самый-самый, а то, что даёт CRM+Invoices покрывает наши нужды процентов на 70. Аналитика и заплаты остались за бортом, я сам накропал для этого на fuel-php небольшую систему учёта и в общем-то творческий поиск остановился.
А еще несколько лет назад, оне вроде бы хотели «высококвалифицированных иностранных специалистов» привлекать. Ну-ну. Тут бы свои не разбежались… И ведь, что не день, то новая «радость». И нет бы хотя бы экономически обосновано, ну с выкладками там или оценками и т.д. и т.п. А то как-то все: бабах — сегодня мысль пришла, бабах — завтра приняли на палитбюро. [Блин] и ругаться низя, а то бы…
П.С. Не то чтобы в европах глупых решений не напринимали. Еще как, целыя мемуары понаписать можно. Но то ведь европы, а то Родина — грустно просто и душа болит.
В этой же статье я описываю разделение на этапы, фиксирование отношений и принцип ценности результата этапа для заказчика.
Вот, кстати, диаграмма по Scrum:
нет ножек нет и мультиковнет инфы нет и помощи, ибо не ясновидящие". Пытаться же наванговать что-то без необходимой информации ведет только к обострению ситуации и демонстрации непрофессионализма со стороны саппорта.В свое время я сделал для молодняка вот такую схему, которую до сих пор успешно используют на том месте в обучении, насколько я знаю. Да и просто в работе:
Самое важное в использовании этого рабочего алгоритма — это корректно осуществлять поиск инфы своими силами, а если не нашли, правильно и полно оформлять запрос на инфу, максимально доступно и прозрачно и все одним письмом. Потому что если вы запросите только часть информации, то в последующем это выливается в «допрос» и загоняет схему в недопустимый для саппорта цикл ненужной переписки.
В идеале, каждый тикет должен закрываться в 1-2 ответа (сразу анализ на месте и ответ, либо запрос инфы => ответ). Только так, и никак иначе.
А чат может выглядеть по итогу так:
"- Эй вы, го***ки, у меня платеж не прошел!
— Здравствуйте, дайте нам %%инфа%%
— Идите в зад, у меня бабки пропали, где мое бабло!?
— дайте нам %%информацию%%
— НЕ мои проблемы, вот вам %%часть инфы%%, больше не помню.
— Поищите
— Мне в лом! Вы поддержка или кто?! Вы тут сидите и фразочки строчите вместо того, чтобы решать мою проблему!
— Мы не сможем вам помочь без %%инфы%%.
— Дайте мне ваше начальство сейчас же, вы не хотите работать!"
И таких будет много.