RU: Открываем дочку американского юридического лица в России

This post is available in English.

И делаем это без необходимости прилета в РФ американского гендира.

Последние полгода я набивал шишки, ходя по инстанциям, собственно, поделюсь опытом 🙂 Задача: открыть 100-процентную дочку в России (материнская SkuVault.com находится в Луисвилле, Кентукки). Наш случай несколько уникален: CEO не мог посетить РФ, так что заверять и пересылать идентификационные документы приходилось туда-сюда меж двух контитентов.

На практике, все делается достаточно просто. Всего-то придется столкнуться с бюрократической машиной Mother Russia (которая за последние годы стала неимоверно удобнее), проблемами с межведомственной коммуникацией, ну да беготней с документами.

Continue reading

How to ensure requirements quality – SkuVault way!

Disclaimer: Every organization is different: from internal structure to how it communicates with the outer world. So no workflow is a silver bullet.

Disclaimer 2: SkuVault is an ever-improving team of ~50 people, distributed across 10 timezones, 2 different versions, and serving loyal clients worldwide 24/7. Learn more about Communication in distributed teams: Messenger & Rules, or Why we ditched Scrum, in favor of Kanban in JIRA

In order to let developer work as productive as possible, management should ensure the following bits related to her work are tackled:

  • Requirements Fallback – whom to ask
  • Issue Description & Decomposition
  • No interruption

We moved closer to ‘no interruption’ bullet by creating on call teams, that are reacting to whatever urgent issues arise. (hållo to Kniberg’s Scrum from the Trenches 2nd edition – our own way of ‘firefighting teams’!).

However, there was no requirements preparation workflow a while back, so as the features grew more complex, more dependencies were discovered, we faced the inevitable given our product size: scope creeps, miscommunication, conclicting scenarios and inconsistency.

In order to bring all departments that were related to requirements eliciting and approval, we’ve created Product Management flow, which had to be highway to hell to better requirements.

Product Management Flow

We aimed to tackle the following areas by creating a formalized workflow:

  • Easy to understand sequence of steps
  • Each step has an accountable person, visible to all participants
  • Workflow encourages Argumentation and Discussion -> no misinterpreted suggestions and details are hashed out collaboratively
  • Each step ensures higher quality requirements, by providing criterias to be met on the output

Workflow consists of sequential steps: New Issue -> Discovery -> Sign Off -> Analysis

IMG_20170822_125022 (1)
mind the typical bad estimation of space on the left 😛

New Issue

Ticket is created by trigger from multiple sources (marketing, services, tech, customer support forums,..). During this state, the ticket is relatively empty, providing only the request and source of the request.

Transition: In order to move the issue to the next stage, Product Owner reviews whether we’ll ever do this feature. If no – he closes it. Yes, sometime – he moves the ticket to Backlog. Yes, near-future – he moves it to Preliminary Analysis.

Preliminary Analysis (Discovery)

Step Goal: Product owner should outline Feature goal (what we need to achieve, benefits for our company and customers); describe basic business process (general 1-2 sentenses on how it works among the warehouse, since we’re a warehousing solutions company); and add that to wiki-page for that feature.

Example: 

Brief feature description

Shipments are a way to track sale items that have been shipped to the customer of the Sale. A Shipment exists in SkuVault once a Tracking Number is assigned by the carrier.We want to provide an ability to connect and save tracking numbers, so that our users can have more visibility and editing right inside the app.

What do we want to achieve
Allow people that use shipping providers that don’t integrate with marketplaces as SkuVault
How it works on the warehouse

Goal: Allow clients to label products with tracking number, and see shipments in relation to Sale they are attached to

  1. Picker gets to the QC table
  2. QC performing person takes the product, QCs it and labels the product with shipping label and tracking number
  3. The tracking number is added to the system and can be visible in relation to the sale
  4. User tracks the product via tracking number

Stakeholder Sign Off

Since there’s quite a stream of tickets, we let Stakeholders approve bunch of tickets at a time. Someone might say ‘Hey, isn’t that Product Owner’s responsibility, to approve?’. Well, first of all our product is big and includes different areas and domains: services, marketing, tech, operations – all having their own pursuits respectively, even if we’re moving towards the same goal.

Step Goal: approve the idea, general process and timeline for the feature to be developed.

The next step would be to gather related parties and start..

Analysis

Analysis is biggest, most collaborative and complex part of the workflow. It involves:

[Business Analysts (creating User Stories)] => [collaborative efforts between BAs / UX / Developers (Wireframing)] <=> [BA / Developers (requirements adjustments, brainstorms, decomposition and clarification)].

Outcome: clear and atomized User Stories with Backend Subtasks with estimates, that give you ability to grasp and plan the feature for development. By you I mean us, Project Managers 🙂

Example: User Story – formalized and easy to grasp description, representing user activity and ability to interact with it.

Precondition: user is on Sale Info page

  1. Before the user clicks a Shipment Tab in the Sale Info page, the hint at the top says “Click a Shipment for Detailed Information”
  2. When the user clicks a Shipment line they see complete Shipment details at the top.
    1. list of fields for Shipments can be seen in Shipments – Plans / Technical Requirements
  3. They can click a button for Shipped Items or Total Cost to see detail for the items.
  4. If a Tracking URL exists for a shipment the user can click it to open the URL in a new tab.
    1. After new tab opens, user is navigated to shipping carrier website with tracking url info
    2. If there is not a tracking url user simple sees “Unknown” instead of the url.
  5. If a Label (ie: PDF) is present, the user can view it in a new tab, or download it by clicking on ‘Download’ button

Post-condition: user is able to see related Shipments info

We got strict rules for creating user stories, technical tasks, support requests and bug reports. This ensures same standards across out task-tracking system (Jira, and properly used Kanban magic) for different issue types, and allows to interpret requirements with the single possible way (which is extremely helpful :).

kanban_board

Nutshell

Right, so in a nutshell, this dramatically increased our requirements quality, and gave us ability to start analysing scope creeps properly, visibility for similar projects and better prognosis. There are things to improve, such as redundancy removal from the requirements, optimizing time spent on the workflow, better communication when estimating client requests – we’re getting closed to that!

Smaller IDEAS tickets - Page 1

one more thing: “oh, author, your flow is redundant for smaller features!”. You’re right, just remove sign off phase and ease analysis to accomodate simple story description  for that feature / improvement ;). 

Why we ditched Scrum, in favor of Kanban in JIRA

Warning: don’t misinterpret scrum for agile as a whole 🙂

Around a year ago I wrote a yearly retrospect on how the workflow at SkuVault is organized, and how we set up our jira boards to work in sprints.

sprints and their goals

There was no Kanban backlog at the moment, and we used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow, I mentioned the reasons in Year Retrospective @ SkuVault. So that sprint-folder system was great, visible and allowed us to predict.

2017-07-16 21.39.59

Yet, in a year period the signal that our approach (sprints as folders) doesn’t quite work appeared – there was a number of tickets migrating from sprint to sprint being rescheduled over and over.

Allow me to add a small note here on SkuVault specifics: There are different categories of work, and planning a common roadmap doesn’t quite work either: we get different priorities from different departments (QA, Product Management, Services and Angry Clients, Services and Happy and Willing to Pay clients) – so the urgent ticket scope inflates. Urgent tickets may require distraction of a developer working on some client request, which shifts the timeline for delivery. So, in a nutshell: there is no unified roadmap between different categories or depts – there is a near-term plan only, with each category having it’s own stack of priorities. Now add to this a remote team that works in collaboration across atlantic and with the timezone difference of 9-10 hours 🙂

worldmap
SkuVault is a distributed team of awesome people, spreading across 9 timezones, or sometimes more. Notice how pathetic I am when it comes to image editing. Those are not cute animals – those are coat of arms symbols, lol 🙂

So a question is: how to remodel the workflow to reflect the specifics?

Buckets and Kanban

We came up with the idea of buckets: basically those are categories of work, originating from different departments with separate product owner responsible for stack of priorities.

Last year Atlassian finally realised the scenarios teams use their product for. So, Backlog for Kanban was born out of desperate cry of thousands of PMs, Teamleads and other people who cannot develop themselves and just drag and drop tickets on the boards (/sarcasm).

The feature came out quite handy and we were able to merge our workflow with our development process IRL.

kanban_backlog_glory
Finally, there’s an option to see upcoming backlog you can both groom and plan inside, and drag that to ToDo as the near-term goals! Don’t forget to estimate that properly 😉

Backlog Kanban allowed us to re-evaluate a lot of backburners that were hanging out there, never getting into the sprints. It also gives us a cleaner board – cause you can store current workload apart from near-term plans, yet in the same board. It’s something you already get with scrum boards, just without sprint management.

Current State

We attacked backburners and development scope from two fronts:

  1. created a separate IDEAS project, where tickets were getting fully fleshed out prior to development;
  2. moved all of the backlog tickets that were on the shelf in development projects back to the IDEAS, to re-evaluate;

This + we’ve added Buckets System, with the support of limited number of devs in the pool for each bucket. I’ll try to write a separate post on how Buckets work in our company later (spoiler alert: they work only as indicators of ticket origins, otherwise – they are kind of not really helping, as of the current state, after some teams shuffling 🙂

Boards, Workflows, and two Backlogs

We’ve got two workflows – one for preparing the ticket for ready-to-be-developed state, the second is for development itself.

Each workflow has it’s own board – as you know, boards are the best ever unicorn rainbow tool to show state of the project from a particular angle.

So two boards reflect those workflows.

IDEAS Board

(Also called pre-development), managed by Product Management. Includes it’s own backlog for backburners, that we put in the shelf for some time (or close to forever); Sign Off, Detalization and Formalization, Architecture Review and finally Ready to Schedule states. Each step has a description and a format of how it should look.

pre-dev-workflow

The point of this board is to reflect status of every single idea that we decided to evolve into a feature, and to see the bottlenecks in Product Management workflow.

pre-development board
Ticket on the right is not violet – it’s just blocker by another Core task
PDM Workflow

Establishing that IDEAS board was also a result of creating full Workflow for Product Management, without letting the ticket out of the IDEAS project and into main SkuVault development project, until all the details and edge cases are fleshed out (well, you caught me – there is no chance you get all 100% of edge cases, but you should try as hard as you can).

By creating standards for each step of formalizing the ticket, we’ve ensured the consistent quality of ready-for-development tickets, which ensured that they won’t be put on hold until clarification from API partner / Client / Product Management. You don’t get big stream of tasks pouring into development, but the quality of such tickets lets developers be distracted less and be more motivated, because who wants to switch context and work on something unfinished.

Development Board

As I pointed out in previous posts – development board is pretty much untouched -> if it works, don’t break it 🙂

SkuVault v1.7 - JIRA 2016-06-08 15-12-47

But the utilization of Kanban Backlog in JIRA came quite handy for both of the boards: you are able to have a set of tickets in the backburner, still in same project, but not wasting ginormous amounts of space on the board -> you just access all backlog via a special planning view.

backlog_predev
Pre-Development Board Backlog

While IDEAS board has a backlog with things, that should sit on the shelf for some time, Development board utilizes kanban backlog in a slightly different manner: I store optimization tickets that we need to check every couple of weeks / months there; as well as User Stories for Epics, that are still in IDEAS, that we didn’t get into development yet; or it’s a very handy way to form a pool of tasks for upcoming developers.

kanban_backlog_glory
Development Board  – Backlog. Two Magento versions support is on hold -> we’ll reevaluate them in the coming months – they’re waiting for their turn.

 

JIRA also support swimlanes for boards, which is utilizied by us in a manner of separating projects one from other:

development board
Three projects in Progress for Shawn -> Lots, QC Improvements, Shipments. The higher the project’s swimlane – the higher it’s priority.

..in a nutshell

  • We’ve ditched sprints, in favor of Kanban. It’s much easier to not pointlessly drag and drop tickets from one sprint to another, if they’re not ready. As I wrote, Urgent tasks needing on call devs contradicts with uninterrupted scrum approach for developing concrete chunks of functionality in a given timebox (mind the fact that scrum and agile as a whole deals with deadlines badly, while we have deadlines most of the time);
  • Kanban gave us differentiation by projects on one board, without making the board too crowded. Scrum boards give that too, but count the hassle of moving unfinished tickets from one sprint to another, which doubles the maintenance work;
  • Kanban Backlog is a great feature, allowing us to manage all tickets in the project. We could have done this in two boards (one for new tickets to be moved to agenda or closed, and another for development / formalization itself) – but now we can manage all tickets in one. Neat.
  • We had an Urgent Board (Kanban Workflow), and Development in Sprints (Scrum) -> now that we moved Development itself to Kanban, we were able to unify the boards, and everything, from minor to blocker tasks, is visible on the same Board! This is great!
  • Never use scrum rituals just for the sake of rituals. We didn’t use sprints for the sake of sprints, we approached sprints as folders and timeboxes. However it’s a common mistake, while management or teams create a cargo-cult for scrum. Most likely you’ll use different practices and methodologies over the time, and finally will come to a hybrid approach that makes you efficient.
  • There are different companies, and certainly there’s no silver workflow bullet for all. So given the maturity / infrastructure / tech. stack / staff – you should model the workflow related and reflecting the flows inside that particular company. SkuVault is changing, growing, scaling – and so is the workflow. Different depts can have different workflows – and we reflect that.

Jira: how to allow editing fields for closed tickets

Jira is flexible, yet complex tool in some cases 🙂

  1. In order to make the fields (inline as well) editable, when the ticket is closed, go to Workflow -> Select ‘Closed’ status -> Click Properties
  2. There would be flags with bool values: we need jira.issue.editable
  3. edit_closed_issue
  4. In case you see jira.issue.editable is false – either change that to true or delete the property key with prev. value.
  5. Don’t forget to publish the updated workflow.

 

So you want to open US-company subsidiary in Russia

This post is available in Russian.

And do it without the CEO flying all the way down to your city 🙂 

Let me share a bit of an experience from past 6 months 🙂 We wanted to open a branch in Russia (parent company is in US). Our case is a bit unique: our CEO wasn’t able to visit Russia, so we had to verify and send the list of docs back’n’forth between two continents.

Actually, that’s not as complex as it seems. You just have to deal with bureaucracy (which dramatically improved over the past years) and intradepartmental miscommunication, and, well, running with pack of docs to veryfy them in both countries.

Let’s get to the basics – list of docs needed to open up a company in Russia:

  • Owner’s passport
  • Application form (to open up an LLC)
  • Decision form (to create a company and assign a general manager)

The list alters just a bit if the owner is to be another company:

  • Documents on establishing parent organization, who owns it and as the russian tax dept states: note from Department of Trade or some analogy
  • The rest is the same as above.

Parent Company Docs in US

Main company docs in US are:

  • Certificate of Existence (when the company was opened and by who);
  • Annual Report (yearly report on company state);
  • Letter of Good Standing (report on company tax health);

You got to file only document originals, signed by Secretary of State!

  1. You take the document originals
  2. You translate them at translational bureau
  3. That bureau should also notarize the translation

There are cases, when company has several owners. I’ll get to it in the section below.

Docs to Confirm Parent Company Owner Identity

Russian Tax dept dreams of all people in the world having same documents, as Russian Citizens (passport, INN (analogue for SSN, that doesn’t allow to steal identity :), SNILS (pension fund info card). So you may be stunned for a sec when a receptionist asks that info from US citizen. And it usually stuns the whole dept, when they are explained that there are no inner passports in US (only for foreign travels). Jesus Christ, those barbarians use non-canonical (USSR-influenced) pack of personal documents -> send in the inquisition..

Well, in reality passport of a US citizen (for a foreign travel) works great. The biggest issue here is that such passport doesn’t contain info on where the person lives (and this is essential in Russian world perception – how can you not be attached to the particular address in your main document?!). This issue is resolved by copying Driver’s Licence that includes living address.

So, in a nutshell, documents company owner needs to send to Russia are:

  • Copy of Passport of a US Citizen
  • Copy of Driver’s Licence

Those documents are processed in Russia, before filing:

  1. Passport and Driver’s Licence are translated
  2. Translation notarized

Now, getting back to the question, where you got multiple company owners. You don’t want the pain to be worse, so you better process docs of CEO, and not co-owners. That will make it easier and won’t require additional signatures on other documents.

Application form

Different branches of Tax Dept want the Application to be filled in different sadistic ways, which I’m not the fan of. If you work with some lawyer firm, that makes it all for you – DON’T BELIEVE A WORD! Well, they will fill up many docs for you and even run and sign them for you. However, some things they cannot do – e.g. verifying signatures of company owner, if he’s not in Russia. In fact, good lawyers on creating international branches can be found in their natural habitat: Moscow and Saint Petersburgh. And since those lawyers don’t work with other regions (they can’t create international branches in other region jurisdictions) – “move along, nothing to see here”.

Many law firms and tax dept themselves will tell you the only option available for Application Form to be filled. It includes:

  • Filling only in Cyryllic and only by parent company owner (bogus – you can have the full document ready, and only to be signed )
  • Signing by owner, with signature verified ONLY in Russia (bogus)
  • Signing by owner, with signature verified ONLY in Russian Consulate (half-bogus).

Getting to the last point: in fact sometimes tax dept may reject signatires not verified by Consulate or some legal Russian Federation entity. That sucks. You know what else sucks (and works!): you can verify owner’s signature on application form at any notary in US (it’s better be Russian-speaking notary, and there are loads of them in almost every country corner – in Louisville, at least, we found one). Why did I mention the ‘sucks’ part? Because Tax dept (and Lawyers) in Russia state that only Consulate should verify signature on application form, but Russian Consulate and Embassy state that US-based notaries (even not speaking Russian ones) have the same power to verify the signature!

Russian Consulate Way

You are lucky! If your CEO got zillions of time to visit Russian Consulates (which are located in the corners of east and west coasts), to schedule appointments there and deal with GRBM (great russian bureacratic machine), which has it’s gears oiled by thick wax, and thus running slow.

While D.C. consulate is fast to reply and it’s quite easy to reach it out by the phone – SF consulate, on the contrary, replied to me after 2 weeks passed. Small hack: you can also verify docs in the consulate you are not attached to (e.g. KY citizen verifying docs in SF) – but clarify that moment first (just in case).

You first have to pick free slot (usually a month or two away from current date), pay consular fee and verify the signature.

  1. You got to pick your company docs (cert. of existence, letter of good standing, annual report) and bring them to the consulate
  2. You got to bring your personal docs (originals and copies of US Citizen Passport and Driver’s Licence)
  3. You got to send already filled forms you want to verify notarize or sign, via email. Not really handy, but tolerable.

After you get into the consulate, you got to verify company owner signature. It should look the following way: signature verified, with stamp of a notary in a consulate. The next page is an info of a notary, that has verified the signature. Notary should also state the number of pages in the document (so that there are no replacements afterwards). Both Application form and Notary page should be stitched together and stamped on the stitched place.

one more thing to mention: if you’re working with lawyer firm, and it handles the filing of docs to the tax depts and social funds, you should write Limited Power of Attorney from the owner to the law firm’s courier (or yourself, if you’re in charge of the branch creation)

Local Notary Way

It’s much faster and easier. CEO signs the application form at any notary, and a notary verifies the signature. It would be ideal, if the notary would enter her notary licence number (in the INN / ИНН) field.

application_last_page

Limited Power of Attorney

In order to file documents for company creation, we got to write Limited Power of Attorney, for one year, for a person who would file it. You will need an original POA and a notarized copy.

limited_PoA

Decision Form

Easiest part is the decision form. CEO should just sign 2 copies of Decision Form, it and stamp them with organization stamp. Don’t worry about non-ink stamps that are common in US – they are accepted in Russia.

Filing: verifying the list

Congrats – you’re finally gathered all of the docs needed! Let’s verify the list:

  1. Parent company: Certificate of Existence (apostilled -> translated into Russian -> translation should be notarized)
  2. Parent company: Annual Report (apostilled -> translated into Russian -> translation should be notarized)
  3. Parent company: Letter of Good Standing (apostilled -> translated into Russian -> translation should be notarized)
  4. Parent company owner / CEO: Driver’s Licence (scanned + printed in Russia -> translated into Russian -> translation should be notarized)
  5. Parent company owner / CEO: US Citizen Passport (scanned + printed in Russia -> translated into Russian -> translation should be notarized)
  6. 2 copies of Decision Form filled in Russian, signed by parent company owner, with parent company stamp on it.
  7. Application Form filled in Russian, signed by parent company owner, with notarized (in US) owner’s signature, and notary’s info attached to the application form. Russian bureaucrats would ideally prefer Application Form and Notary’s Note on number of pages stitched together, and stamped in the stitched place, so that no pages could be replaced afterwards. But that’s not mandatory.

That’s all folks! Don’t forget to take confirmation papers on documents receiving by the tax dept, as well as OGRN / INN papers, and certificate of existence in Russia. Keep 2nd copy of Decision form to yourself as well, you may needed it in the bank or some other institution sometimes.

Russia is great, don’t let bureacracy ruin the experience! 😉

References:

  1. Decision form: https://www.regberry.ru/registraciya-ooo/obrazcy-dokumentov/reshenie-edinstvennogo-uchreditelya-obrazec
  2. Application Form: https://www.regberry.ru/registraciya-ooo/obrazcy-dokumentov/forma-r11001-zapolnenie

Communication in distributed teams: Messenger & Rules

In order for the distrubited teams to work, you got to have a clear flow, a set of general rules, that will fence the process and allow people to collaborate effectively around the globe. If everything is set up correctly, you are able to create amazing products with global professionals, and cover customer support 20+ hours a day.

Communication

What do you miss most when working outside of the office? Procrastination!

Communication that is effortless in office envoronment may be not as natural in distributed teams.

Messenger (SkuVault uses Telegram, chosen for it’s simplicity, availability across all platforms, stability gorgeous GIF bot) and videochat software are there to try to equally substitute verbal communication.

Due to project specifics, we have the following channels in telegram:

  • Urgent chat, where On Call & Quality Assurance teams collaborate in order to resolve outstanding issues as fast as possible (you can read more about On Duty teams in my previous post on year retrospective);
  • Dev chat, that is general for all devs, covering the questions of “Who the hell broke QA again?”, …, to “So have you seen Azure copied Amazon pricing plan”.
  • Russian Dev chat, due to significant part of the team being russian-speaking, is for fast communication and clarification across russian devs;
  • Quality Assurance chat, for questions and discussions across QA members;
  • Freshdesk feed, for fetching freshly issues support tickets, so that if immediate attention needed -> relevant people are informed;
  • separate project chats with various messaging activity, depending on how big and urgent the project is.

Telegram

Telegram is extremely handy when it comes to making life easier. We use:

  • hashtags, to mark needed messages in order to find them later. That could be #shipstation hashtag to mark everything related to ShipStation integration across all chats;
  • mentions, which allow to ping a person even if the chat is muted. So if dev doesn’t want to get tons of messages on a related subject, he still is notified when he’s mentioned;
  • great gif support (not only kittehs, but also when you need gif with reproduced bug);
  • bots! we fetch freshdesk support tickets, notified about engine and web errors thanks to telegram bot api 🙂
  • size, platform availability, stickers, e.t.c.

now this sounds like a telegram evangelism

Video Conference

When it comes to video conferencing, we use hangouts, since skype app is awful.

General Flow and Jira Ticket Descriptions

It’s bad when you lack information on stuff you need to implement. In order to minize that, we have rules on filling out the ticket, so that as less questions as possible are raised.

Ticket description has testing plan, implementation plan, sequence of steps on how the feature should work, client and needed sandbox credentials, and tons of other information. Now that doesn’t prevent requirements change, scope creeps, blind spots (we all know that software development is an endless pain and all related people should suffer), but it surely reduces questions to clarify / misunderstanding / delays to the bare minimum and greatly helps in communication.

General Flow for the ticket before it hits implementation requires it’s acceptance by PM and dev, so those are members who control whether ticket is clear enough or not.

Workplace Attendance

Although you are not obliged to come to the office, it’s still essential to be at your workplace during working hours. If you’re working flexible hours, you need to agree upon them with a manager or people you collaborate with, so that you have a consensus solution on comfortable time to work for all.

Calendar lists days off, while chatrooms are good to inform colleagues about hours off, if necessary.

Working remote takes self-dicipline and responsibility, but pays off really great.

Notifications for pinging stuck projects

Be sure you use various notifications, such as jira web hooks + telegram, email notifications on stuck code review or testing, color coding on project management boards for due dates and approaching deadlines. Alltogether, those measures prevent unexpected situations and make the risk of missing deadlines, reduces the risk of tickets stuck halfway, keeps you alarmed in almost all cases where the flow takes wrong direction.

Project Management & Business Analysis Meetup – Ufa

So it happened – I managed to gather 2 people for PM & BA meetup (without any PR xD).

After visiting Vienna, I desperately wanted a platform to share knowledge or / and mock each other on PM & BA failures. So I created one:  Ufa Project Management & Business Analysis Group 

Initial meeting consisted of Me, Nur (from modulbank.ru – online bank for small businesses) and Oleg (from smena.io – various crms / solutions for partners). Both work as analysts at cool and interesting teams.

So thank you, @Nur and @Oleg 🙂 First meeting went nicely, at my favourite coffe place Chat House. Meetup went as expected: we’ve shared experience and discussed who works via which workflow, how we formalize requirements and what are the places we store them.

I miss good ole Ufa42 Conference, I think we gotta revive it 🙂